Retry webhooks without creating duplicate work
A webhook sender may repeat the same event after a timeout. Your integration needs to recognize the event without pretending the first attempt failed.
- Published
- Updated
- Reading time
- 6 min read
Tested environment Synthetic HTTP requests with repeated event identifiers and controlled response timeouts.
Give the event an identity
Use the sender’s stable event identifier when it exists. When it does not, agree on a deterministic key made from fields that do not change between attempts. Store that key with the accepted work before answering the sender.
Separate receipt from completion
An HTTP success response can mean the event is durably accepted. It does not need to mean every downstream side effect has completed. Keep that distinction visible in run history so support staff can answer what happened without guessing.
Make replay a rule
Record whether a failed destination is safe to retry, needs a person or must never run twice. A timeout does not prove that the remote system rejected the request. Treat that outcome as ambiguous until evidence resolves it.
What this does not cover
This guide does not choose a business identifier for a specific vendor API. Confirm the sender’s documented retry contract and authentication rules before release.