Replay the original event, not an approximation
A reliable replay starts with the original request method, path, headers and body. Rebuilding a payload by hand can remove a field, change a timestamp, or break the provider signature. An event record lets you recover the delivery with evidence of exactly what arrived.
Before replaying, choose the destination deliberately. A local target helps validate a fix. A staging target can exercise the surrounding integration. A production target deserves an explicit confirmation because it can trigger real customer-facing work.
Idempotency is the safety net
Providers retry webhook deliveries, and operators may replay the same event while investigating. Your handler needs a durable way to recognize an event it has already processed. Store the provider event identifier, or a deterministic idempotency key, before creating a charge, sending an email, or mutating an order.
Idempotency does not mean a replay should be invisible. Record why it was requested, where it was sent and what response came back. That history is what makes an operational recovery reviewable later.
Use a deliberate replay checklist
A short checklist prevents a useful recovery tool from becoming a source of accidental duplicate work.
- Confirm the event identity and inspect the raw request before sending it again.
- Select a target explicitly; never infer a production URL from a previous action.
- Redact or protect sensitive headers in the interface and in logs.
- Require an explicit confirmation for a production replay.
- Save the request time, target, response status and response excerpt with the replay record.
Know when not to replay
Do not replay an event if the provider has already confirmed a successful retry, if the downstream effect is not idempotent, or if the event contains time-sensitive instructions that are no longer valid. In those cases, use a domain-specific repair action instead of sending an old request again.