Webhook Replay

What you can build

• Recover an hour of Stripe events after an outage

  Events with delivery_success false are matched against Webhook Ingest receipts. Ones the receiver already accepted on a retry are dropped. The remaining event ids form one resend list, grouped by object, for approval.

  With Stripe, Webhook Ingest

• Redeliver GitHub pull_request events a deploy dropped

  Hook deliveries with a 5xx status_code during the deploy window are listed by guid. The operator proposes one redelivery attempt per guid, in delivered_at order, and skips any guid already marked redelivery.

  With GitHub, Webhook Ingest

• Rebuild Shopify orders after a subscription was deleted

  When a subscription vanishes after four hours of failures, the operator proposes re-registering it and a reconciliation fetch of orders updated in the gap, so the order feed carries on without a manual export.

  With Shopify, Webhook Ingest

Requirements

• A Stripe restricted key that reads events, a Shopify custom app with webhook and order scopes, or a GitHub token with read:repo_hook and write:repo_hook
• Webhook Ingest as the receiver, or a receiver log that records delivery ids, so the match has something to compare against
• Signature secrets kept current in Webhook Ingest, since a replayed delivery is signed afresh by the sender
• An agreed order for replays per event type, such as created before updated, where the receiver depends on it

Authentication

Reads delivery logs with the sender connectors' keys and receipts from Webhook Ingest's own records. It writes only the redelivery or subscription calls you approve.

Limits

• Stripe does not guarantee event order and can send an event twice. The batch is deduplicated by event id; order is rebuilt from the objects.
• Stripe retries for up to three days in live mode; Dashboard Resend works for 15 days. After 30 days only the object can be fetched.
• Shopify retries 8 times over 4 hours, then deletes a subscription made through the Admin API. Deliveries lost after that have no sender log.
• GitHub keeps deliveries available for redelivery for 3 days. Older misses are recovered by fetching the object, not by redelivery.

Questions and answers

What do I approve before anything is replayed?

One batch. It lists each event id or delivery guid, the sender, the failure status the sender logged, and whether the receiver already holds it. You can strike entries out, change the order, or hold the batch until the receiver is healthy.

How does it avoid duplicates?

It keys on the sender's own identifier: the Stripe event id, X-Shopify-Webhook-Id, or the GitHub delivery guid. Anything Webhook Ingest already accepted, on the first attempt or a retry, is excluded. A replay batch is applied once. Running it again produces nothing new.

What record is left?

A receipt per batch: the ids replayed, the ids skipped and why, the endpoint called, the sender's response per attempt, who approved, and when. Receipts stay attached to the outage window, so the next audit shows what was recovered.