Följ upp och spela upp webhook-leveranser igen

Historisk tillbakablick – mars 2026
Den här artikeln skrevs i efterhand och beskriver den publika leveranslogg som tillkom under perioden.

När en webhook-mottagare inte svarar som väntat kan du undersöka leveransen utan att manuellt skapa en ny affärshändelse. Öppna leveransloggen i Alunta eller hämta listan via API:et för att se status, försök och publika leveransuppgifter.

En leverans med statusen failed betyder vanligtvis att du behöver rätta mottagaren eller dess validering. Dispatching betyder att leveransen fortfarande skickas. API:et använder även succeeded för en slutförd leverans. I filter utesluter failed leveranser vars status är dispatching; använd det separata värdet dispatching om du vill se dem. Använd den aktuella API-referensen för exakta fältnamn och statusar.

Spela upp en leverans igen

Välj en misslyckad leverans och använd åtgärden för att spela upp den igen. En uppspelning skickar samma externa meddelande på nytt; den skapar ingen ny prenumerations- eller fakturahändelse. Mottagaren måste därför deduplicera data.event_id när händelsetypen dokumenterar en stabil nyckel, använda webhook_uuid som leveransidentitet när det finns och tåla att samma händelse kommer mer än en gång. Behåll separata subscription.payment_failed-försök som separata leveranser.

Uppspelningen rättar inte automatiskt ett fel i ditt system. Kontrollera först ändpunkt, signaturverifiering och händelsehantering och använd sedan leveransloggen för att bekräfta resultatet.

Se guiden om publikt API och webhooks (Markdown-fil, AI-agentvenlig) för aktuellt flöde för loggning och uppspelning.

Ett säkert flöde för uppspelning

Använd en påhittad, obefintlig händelse med UUID:t 00000000-0000-4000-8000-000000000004 i testmottagaren. Innan du spelar upp den kontrollerar du att mottagaren sparar relevant stabil händelsenyckel och svarar snabbt. För en händelsetyp med data.event_id skickar uppspelningen samma nyckel igen, och mottagaren kör inte affärsåtgärden två gånger; när webhook_uuid finns identifierar den leveransen. Kontrollera sedan leveransstatusen. Behåll separata subscription.payment_failed-försök. Om den fortfarande misslyckas rättar du mottagaren igen i stället för att skapa en prenumerationshändelse manuellt.

En uppspelning skickar ett meddelande igen, inte en betalning. Om det externa systemet startar en åtgärd utifrån händelsen måste även den åtgärden vara idempotent.

När statusen inte ändras

En lyckad uppspelning betyder att mottagaren accepterat leveransen, inte att den interna behandlingen är korrekt. Använd både Aluntas leveransstatus och din egen mottagningslogg. dispatching är inte samma sak som failed eller succeeded, och ingen av dessa statusar är i sig en prenumerations- eller betalningsstatus.

Om en uppspelning skickar en händelsetyp du inte längre använder ska mottagaren fortfarande hantera den säkert och markera den som ignorerad enligt sin policy. Ta inte bort historiken för att ”rätta” ett fel; rätta mottagaren och använd den dokumenterade uppspelningsåtgärden.