Webhook Guides
Webhook Replay
Webhook replay is the recovery path for events that were received but not processed correctly by a downstream API. A provider can see 200 OK at ingress while the destination, database write, queue job, or side effect still fails later.
FastHook stores the inbound request, routed event, and delivery attempts so teams can inspect the failure, fix the receiver, and replay the affected webhook event without copying payloads out of scattered logs.
Why replay exists
Replay exists because webhook delivery has more than one success boundary. The producer only knows whether the endpoint accepted the request. Your team still needs evidence that the event reached the right destination and produced the expected downstream result.
- A receiver timed out after FastHook accepted the provider request.
- A destination returned 500 or 429 during a deploy or API outage.
- A transformation or filter was fixed after a narrow set of events was misrouted.
- A support engineer needs to recover a missed invoice, order, lead, or repository event.
Replay failed webhooks safely
Replaying a webhook should be a controlled operation. FastHook lets operators inspect the original payload, latest attempt, response status, and failure message before retrying the event. That keeps recovery tied to evidence instead of guesswork.
- Find the failed event or request in FastHook logs.
- Read the destination attempt response and failure message.
- Fix the receiver, credentials, rate limit, transformation, or route.
- Confirm the receiver is idempotent for the event id or business object id.
- Replay one event first, then widen the recovery window if the result is correct.
Replay after downstream API failures
Downstream APIs fail in ordinary ways: deploys, expired credentials, validation changes, temporary throttling, slow databases, and network errors. If the original webhook was persisted before delivery, recovery can happen after the downstream system is healthy again.
FastHook keeps request, event, and attempt records together, so the replay action can use the stored event rather than asking the provider to resend or asking engineers to rebuild a payload manually.
Recover missed webhook events
Missed events usually appear as missing rows, missing notifications, incomplete orders, stale billing state, or support tickets where the provider says the webhook was delivered. Replay helps after you have found the failed delivery attempt and fixed the downstream cause.
- Recover a missed Google Sheets row after a temporary API failure.
- Replay a missed Slack alert after fixing channel permissions.
- Redeliver a Stripe event after a billing receiver outage.
- Replay only the affected branch when one destination failed and others succeeded.
Replay vs retry
| Recovery path | Use it when | Operational risk |
|---|---|---|
| Automatic retry | The destination returns a transient 429 or 5xx. | Duplicate side effects if the receiver is not idempotent. |
| Manual event replay | An operator fixed the receiver and wants to redeliver a known failed event. | Replaying the wrong event window. |
| Request replay | The original request should pass through current routing again. | New filters or transformations may produce different branches. |
Replay and idempotency
Replay is dangerous when the receiver treats every delivery as a new business action. Store a provider event id, delivery id, or object id before creating side effects, then make repeated deliveries safe.
- Use Stripe event ids, GitHub delivery ids, Shopify webhook ids, or your own idempotency key.
- Separate event receipt from downstream side effects where possible.
- Keep duplicate detection near the receiver that creates the side effect.
- Use FastHook attempt logs to confirm whether a replay created a new delivery attempt.
Replay, logs, deduplication, and debugging
Replay should start from logs, not from guesswork. Inspect the request, event, attempts, response body, and deduplication key before redelivering traffic.
- Use debugging logs to identify the failure boundary.
- Use retries for temporary failures and replay for operator-controlled recovery.
- Use deduplication and idempotency to make duplicate events safe.
- Use branch-level attempt logs when one webhook fans out to multiple destinations.
Webhook replay FAQ
Does 200 OK mean the webhook was processed?
No. It only confirms the request was accepted at that boundary. Delivery, routing, and receiver processing can still fail afterward.
Should every failed webhook be replayed?
No. Inspect the failure first, fix the underlying cause, and verify idempotency before replaying traffic.
Can replay help after a receiver outage?
Yes. Once the receiver is healthy, stored events can be replayed through the delivery path with attempt evidence attached.