Følg og gentag webhook-leveringer

Historisk tilbageblik - marts 2026
Denne artikel er skrevet efterfølgende og beskriver den offentlige leveringslog, som blev tilføjet i perioden.

Når et webhook-endpoint ikke svarer som forventet, kan du undersøge leveringen uden at oprette en ny forretningshændelse manuelt. Åbn leveringsloggen i Alunta eller hent listen gennem API’et, og se status, forsøg og de offentlige leveringsoplysninger.

En levering med status failed kræver typisk, at du retter modtageren eller dens validering. Dispatching betyder, at leveringen stadig er under afsendelse. API’et bruger også succeeded for en gennemført levering. Ved filtrering udelukker failed leveringer med status dispatching; brug den særskilte dispatching-værdi, når du vil se dem. Brug den aktuelle API-reference til præcise feltnavne og statusser.

Gentag en levering

Vælg en fejlet levering, og brug handlingen til at gentage den. En replay sender den samme eksterne besked igen; den opretter ikke en ny subscription eller invoice event. Modtageren skal derfor deduplikere data.event_id, når eventtypen dokumenterer en stabil nøgle, bruge webhook_uuid som leveringsidentitet, hvor den findes, og tåle at se samme hændelse mere end én gang. Separate subscription.payment_failed-forsøg skal fortsat behandles som separate leveringer.

Replay reparerer ikke automatisk en fejl i dit eget system. Kontrollér først endpoint, signaturkontrol og eventbehandling, og brug derefter leveringsloggen til at bekræfte resultatet.

Se vejledningen til offentlig API og webhooks (Markdown-fil, AI-agentvenlig) for den aktuelle log og genafsendelse.

Et sikkert replay-forløb

Brug en fiktiv, ikke-eksisterende event med UUID 00000000-0000-4000-8000-000000000004 i din testmodtager. Før replay kontrollerer du, at modtageren gemmer den relevante stabile eventnøgle og svarer hurtigt. For en eventtype med data.event_id leverer replay den samme nøgle igen, og modtageren udfører ikke forretningshandlingen to gange; hvor webhook_uuid findes, er den leveringsidentiteten. Kontrollér derefter loggens status. Bevar separate subscription.payment_failed-forsøg. Hvis leveringen stadig fejler, ret modtageren igen i stedet for at oprette en manuel subscription-hændelse.

Replay gentager en besked, ikke en betaling. Hvis det eksterne system udløser en handling på baggrund af eventet, skal den handling også være idempotent.

Når status ikke ændrer sig

En succesfuld replay betyder, at leveringen blev accepteret af modtageren, ikke at modtagerens interne behandling er korrekt. Brug derfor både Aluntas leveringsstatus og din egen modtagelseslog. dispatching er ikke det samme som failed eller succeeded, og ingen af statusserne er i sig selv en abonnements- eller betalingsstatus.

Hvis en replay sender en eventtype, du ikke længere bruger, skal modtageren stadig håndtere den sikkert og markere den som ignoreret efter sin egen politik. Slet ikke historikken for at “løse” en fejl; ret modtageren og brug den dokumenterede replay-handling.