Replay a Failed Webhook Without Re-Triggering the Provider

Re-triggering means creating another test charge, pushing another commit or waiting for the next real customer. The new event has a different ID and often different data, so you are no longer debugging the request that failed. Provider redelivery (Stripe's resend, GitHub's Redeliver in Recent Deliveries) keeps the payload but only goes to the URL registered with the provider, and you can't edit it.

Replaying from a captured copy gives you the same bytes every time, sent to whichever environment you are fixing.

1. Sign in at app.hooklistener.com and open the endpoint that received the webhook.
2. Select the failed request in the history list.
3. Choose Replay and enter the destination URL, for example https://staging.example.com/webhooks/stripe.
4. Optionally add headers or edit the body. If you change the body of a Stripe, GitHub or Slack webhook, re-sign it so your signature check still passes.
5. Send it, read the response, and replay again after each fix. Each attempt is recorded so you can compare responses.

Your handler runs on your laptop, so it needs a way to receive the replay. Install the CLI and sign in:

npm install -g hooklistener
hooklistener login

Option A: replay to a tunnel URL

Open a tunnel to your local port and use the public URL it prints as the replay destination:

hooklistener tunnel --port 3000
# Forwarding: https://abc123.hook.events → http://localhost:3000

Replay the failed request to https://abc123.hook.events/webhooks/stripe and it lands on localhost:3000/webhooks/stripe. Requests that come in through the tunnel are captured too, so they can be replayed later. See the tunnel command reference for persistent subdomains and other options.

Option B: listen to the endpoint your provider already uses

If Stripe or GitHub already sends to a Hooklistener endpoint, forward that endpoint to your machine and replay from the dashboard:

hooklistener listen --endpoint ep_abc123 --port 3000 --path-prefix /api/webhooks

The CLI sends each request to your local server with the same method, headers and body, and logs your server's response. Details are in the listen command reference.

With the Hooklistener MCP server connected, Claude Code, Codex or Cursor can find the failed request and replay it in one prompt:

> Find the last Stripe request on my endpoint that my handler
  rejected and replay it to https://abc123.hook.events/webhooks/stripe.
  Tell me the response status.

The agent calls replay_request, which can send the request to any URL or your CLI tunnel, with an edited body and optional Stripe, GitHub or Slack re-signing. To keep the request as a test, it can call save_request_case and later run_endpoint_cases to replay the whole suite. For a full session, see debugging Stripe webhooks with Claude Code.

Signature timestamps

GitHub signs only the body, so an unedited replay verifies no matter how old it is. Stripe's Stripe-Signature and Slack's signature also cover a timestamp, and the official libraries reject old ones (stripe-node's default tolerance is 300 seconds), so an unedited replay of an older request fails verification. Fix it by re-signing instead of loosening the tolerance: store the provider's signing secret in Hooklistener, then call replay_request with signing_provider and signing_secret_id. The signature header is generated at delivery with a fresh timestamp, so the replay verifies against your real secret and default tolerance, in production as well as locally.

> Replay request req_abc123 to https://api.example.com/webhooks/stripe,
  re-signed with signing_provider "stripe" and my stored whsec_ secret.

Stored signing secrets are on paid plans; capture and replay work on every plan. Keep your tolerance where it is, since it is your protection against replay attacks. More in the Stripe webhook security guide and webhook signing and HMAC verification.

Idempotency checks

A replay carries the original event ID, so a handler that deduplicates correctly will skip it. That proves deduplication works; to exercise the processing path again, clear the ID in your dev database. See webhook idempotency and deduplication.

• Stripe: verify against the raw body. Most replays that still fail with "No signatures found matching the expected signature" come from a JSON body parser running before the webhook route. See the Stripe webhook debugger and the Stripe local testing guide.
• GitHub: a replay keeps the original X-GitHub-Event and X-GitHub-Delivery headers, so your router and dedup logic see the same delivery. See the GitHub webhook debugger and the GitHub repository webhooks guide.