Resend webhook delivery: idempotent handlers, retry schedule, replay

Webhook delivery ops: be idempotent, be fast, know the retry schedule

If your endpoint does not return HTTP 200, Resend retries with exponential backoff: immediate, 5 seconds, 5 minutes, 30 minutes, 2 hours, 5 hours, 10 hours.

Steps

1. Make every handler idempotent. Dedupe on the svix-id header (unique per message) or the event id before doing any side effect: check your processed-events store first, record it, then act. Retries and replays will redeliver the same event.
2. Return 200 quickly, then process asynchronously. A slow handler that times out triggers a retry of work that already succeeded, which is how duplicate emails and double-charged follow-ups happen.
3. Return non-200 only when you genuinely failed and want a retry. Returning 200 for an event you cannot handle yet is a lie; fix the handler instead.
4. When events go missing, debug with the delivery history API: list events on the webhook, inspect each attempt's HTTP status code and response body, and replay the event from the dashboard or API to reprocess it with fixed handler code.

The trap

A handler that is neither idempotent nor fast. The retry schedule will redeliver into it for 10 hours, and every redelivery re-runs your side effects. The other trap is treating a replayed event as suspicious: replays are a normal operations tool, and your idempotency dedupe is what makes them safe.

The retry schedule (immediate, 5s, 5m, 30m, 2h, 5h, 10h), the return-200-fast guidance, manual replay from the dashboard, and the events/attempts delivery-history API are documented in the official resend-skills webhooks reference at https://raw.githubusercontent.com/resend/resend-skills/HEAD/skills/resend/references/webhooks.md. Webhook retry and replay from the dashboard or API are documented at https://resend.com/docs/webhooks/introduction.