Følg med på og spill av webhook-leveringer på nytt
Historisk tilbakeblikk – mars 2026 Denne artikkelen ble skrevet i ettertid og beskriver den offentlige leveringsloggen som ble lagt til i perioden.
Historisk tilbakeblikk – mars 2026
Denne artikkelen ble skrevet i ettertid og beskriver den offentlige leveringsloggen som ble lagt til i perioden.
Når en webhook-mottaker ikke svarer som forventet, kan du undersøke leveringen uten å opprette en ny forretningshendelse manuelt. Åpne leveringsloggen i Alunta, eller hent listen via API-et for å se status, forsøk og offentlige leveringsopplysninger.
En levering med status failed betyr vanligvis at du må rette mottakeren eller valideringen dens. Dispatching betyr at leveringen fortsatt sendes. API-et bruker også succeeded for en fullført levering. I filtre utelukker failed leveringer med status dispatching; bruk den separate verdien dispatching når du vil se dem. Bruk den gjeldende API-referansen for nøyaktige feltnavn og statuser.
Spill av en levering på nytt
Velg en mislykket levering, og bruk handlingen for å spille den av på nytt. Avspillingen sender den samme eksterne meldingen igjen; den oppretter ikke en ny abonnements- eller fakturahendelse. Mottakeren må derfor deduplisere data.event_id når hendelsestypen dokumenterer en stabil nøkkel, bruke webhook_uuid som leveringsidentitet når den finnes, og tåle å se samme hendelse flere ganger. Behold separate forsøk på subscription.payment_failed som separate leveringer.
Avspilling retter ikke automatisk feil i systemet ditt. Kontroller endepunktet, signaturverifiseringen og hendelseshåndteringen først, og bruk deretter leveringsloggen til å bekrefte resultatet.
Se veiledningen for offentlig API og webhooks (Markdown-fil, AI-agentvenlig) for den gjeldende arbeidsflyten for logg og avspilling.
En trygg arbeidsflyt for ny avspilling
Bruk en fiktiv, ikke-eksisterende hendelse med UUID-en 00000000-0000-4000-8000-000000000004 i testmottakeren. Før du spiller av på nytt, kontrollerer du at mottakeren lagrer den relevante stabile hendelsesnøkkelen og svarer raskt. For en hendelsestype med data.event_id leverer avspillingen den samme nøkkelen igjen, og mottakeren kjører ikke forretningshandlingen to ganger; når webhook_uuid finnes, identifiserer den leveringen. Kontroller deretter leveringsstatusen. Behold separate forsøk på subscription.payment_failed. Hvis leveringen fortsatt mislykkes, retter du mottakeren igjen i stedet for å opprette en abonnementshendelse manuelt.
Avspilling gjentar en melding, ikke en betaling. Hvis det eksterne systemet starter en handling på grunnlag av hendelsen, må også den handlingen være idempotent.
Når statusen ikke endres
En vellykket avspilling betyr at mottakeren godtok leveringen, ikke at den interne behandlingen er korrekt. Bruk både leveringsstatusen i Alunta og din egen mottakslogg. dispatching er ikke det samme som failed eller succeeded, og ingen av disse statusene er i seg selv en abonnements- eller betalingsstatus.
Hvis en avspilling sender en hendelsestype du ikke lenger bruker, bør mottakeren fortsatt håndtere den trygt og markere den som ignorert i samsvar med retningslinjene dine. Ikke slett historikken for å «rette» en feil; rett mottakeren, og bruk den dokumenterte avspillingshandlingen.
Menneskene og KI-hjelperne bak oppdateringene
Bo Møller og Emil Højbjerg er hovedutviklerne bak Alunta. De bruker mesteparten av tiden på å kode og har derfor overlatt formuleringen av disse forklaringene til KI-hjelperne våre.
KI-hjelperne skriver med utgangspunkt i oppdateringene vi har publisert. Bo og Emil står bak endringene og har ansvar for at informasjonen gjenspeiler det som faktisk er lansert.
