Testing Webhook Retry Behavior

Configure a failure

Use a sandbox sender and an endpoint you can manage. In Response, manually save HTTP 500. Record the original configuration so you can restore it after the experiment. See custom response setup.

Trigger a delivery

Manually trigger one delivery from your sender. If testing with cURL, set WEBHOOK_URL as in Quickstart and send:

curl --include --request POST "${WEBHOOK_URL}/response-test" \
  --header 'Content-Type: application/json' \
  --data '{"test":true}'

Expect the configured HTTP 500 and one captured request. One ordinary cURL invocation performs one HTTP request and schedules no later attempts; running the command again is a separate manual send.

Compare attempts

Next, manually change and save the endpoint response to HTTP 503. Manually send the cURL request again or request one provider redelivery, then confirm a second capture and 503 result. Finally, manually reset and save HTTP 200, send or redeliver once more, and confirm a third capture and 200 result.

Record attempt times and delivery identifiers and compare them with request timestamps, IDs, bodies and response statuses. Repeated bodies may be duplicate delivery attempts; a new capture is not proof of a new business event. WebhookKit does not schedule retries, and this controlled three-request exercise does not demonstrate a provider’s automatic schedule.

Synthetic controlled redelivery comparison, all times UTC. These are three distinct HTTP requests for the same business event, not a provider retry schedule.

A saved custom 4xx or 5xx response can accompany a successful capture. If a sender reports a timeout or service error, check history before resending: persistence may already have succeeded and a resend can create a duplicate.

Current provider behavior

Stripe: sandbox deliveries are currently retried three times over a few hours; live-mode delivery uses exponential backoff for up to three days. A manual resend does not cancel the automatic sequence. See Stripe event delivery behavior.

GitHub: failed deliveries are not automatically redelivered. An authorized user can manually redeliver an eligible delivery from the past three days. See GitHub redelivery instructions.

Restore success

After confirming the manual 200 result, leave the endpoint at the intended successful response or select Reset to default. Disable the temporary test destination when finished. Provider automation, if any, remains separate from the three deliberate sends above.