Webhook Replay

Webhook replay is the ability to re-send a webhook event that a receiver missed or mishandled — either automatically as part of a retry policy, or on demand from a dashboard or API. It exists because delivery is not the same as processing: an endpoint can return 200 and then fail on the database write, a deploy can drop in-flight requests, and an outage can put an hour of events beyond the provider's automatic retry budget. Without replay, the only recovery is a full reconciliation against the provider's API, which is slower and often incomplete. The receiver's side of the contract is idempotency. Any replay mechanism guarantees at-least-once delivery, so the consumer must be able to process the same event twice without doubling a charge, sending a second email or inserting a duplicate row. In practice that means recording the provider's event identifier and rejecting one already seen, and making the resulting write keyed rather than additive. Two more details matter. Order is not preserved on replay: an event re-sent an hour late can arrive after a later event about the same object, so handlers should reconcile against the current state — or check the event's own timestamp or version — rather than assume a sequence. And a replayed request must be verified exactly like a live one, since a replay endpoint that skips signature checking is an unauthenticated way into your system. For teams building webhooks, offering replay plus a visible delivery log is one of the highest-value integration features you can ship.