Follow and replay webhook deliveries

Historical retrospective - March 2026
This article was written afterwards and describes the public delivery log added during the period.

When a webhook receiver does not respond as expected, you can investigate the delivery without creating a new business event manually. Open the delivery log in Alunta or fetch the list through the API to see status, attempts, and public delivery details.

A delivery with failed status usually means that you need to fix the receiver or its validation. Dispatching means the delivery is still being sent. The API also uses succeeded for a completed delivery. In filters, failed excludes deliveries whose status is dispatching; use the separate dispatching value when you want to see them. Use the current API reference for exact field names and statuses.

Replay a delivery

Select a failed delivery and use the replay action. A replay sends the same external message again; it does not create a new subscription or invoice event. The receiver must therefore deduplicate data.event_id when the event type documents a stable key, use webhook_uuid as delivery identity where available, and tolerate seeing the same event more than once. Keep separate subscription.payment_failed attempts as separate deliveries.

Replay does not repair an error in your system automatically. Check the endpoint, signature verification, and event handling first, then use the delivery log to confirm the result.

See the public API and webhooks guide (Markdown file, AI agent-friendly) for the current log and replay workflow.

A safe replay workflow

Use a fictional, nonexistent event with UUID 00000000-0000-4000-8000-000000000004 in your test receiver. Before replaying, check that the receiver stores the relevant stable event key and responds quickly. For an event type with data.event_id, replay delivers the same key again and the receiver does not run the business action twice; where webhook_uuid is present, it identifies the delivery. Then check the delivery status. Retain separate subscription.payment_failed attempts. If it still fails, fix the receiver again instead of creating a manual subscription event.

Replay repeats a message, not a payment. If the external system starts an action because of the event, that action must also be idempotent.

When the status does not change

A successful replay means that the receiver accepted the delivery, not that its internal processing is correct. Use both Alunta’s delivery status and your own receipt log. dispatching is not the same as failed or succeeded, and none of these statuses is itself a subscription or payment status.

If a replay sends an event type you no longer use, the receiver should still handle it safely and mark it ignored according to its policy. Do not delete history to “fix” an error; fix the receiver and use the documented replay action.