How It Works

The capture, store, forward, and retry flow explained

Hookdrop sits between your webhook provider and your server:

Provider (Stripe, GitHub, …) → Hookdrop → Your server

When an event arrives, Hookdrop handles it in six phases — so your server can be slow, restarting, or temporarily down without losing a single event.

1. Capture

   The event hits your permanent Hookdrop URL. Hookdrop saves it immediately and returns 200 OK to the sender in under 50ms.

   Most webhook providers treat a slow or missing response as a failed delivery and start retrying — sometimes within seconds. By responding instantly, Hookdrop prevents the sender from firing duplicate events before your server has had a chance to process the first one.

2. Store

   The full event — headers, body, source IP, and timestamp — is persisted to durable storage. It stays there for the duration of your plan’s retention period, so you can inspect or replay it at any time.

3. Forward

   Hookdrop forwards the event to every destination configured on your endpoint. Each delivery attempt has a 10-second timeout. You can add multiple destinations — for example, your local dev server and your staging environment at the same time.

4. Retry

   If your server returns an error or doesn’t respond in time, Hookdrop retries automatically using exponential backoff:

   Attempt	Delay
   Initial attempt	Immediately on event capture
   1st retry	5 seconds after failure
   2nd retry	~25 seconds after 1st retry
   3rd retry	~2 minutes after 2nd retry
   4th retry	~10 minutes after 3rd retry

   After 4 failed retries, the event moves to the dead letter queue and you receive an email alert.

5. Audit

   Every delivery attempt is logged with the response code, response body, and timestamp. You get a complete audit trail for every event — useful for debugging failures and confirming delivery.

6. Replay

   At any point, you can replay any event to any destination with one click. This works regardless of the original delivery outcome, and you can replay to a different destination than the original — useful when testing a new server or recovering from an outage.