Webhook Delivery Simulator
Send a webhook through a production-style delivery flow. Change endpoint responses, watch retries and backoff, inspect real HMAC-SHA256 signatures, and redeliver the same message to see receiver-side deduplication.
Category: DevOps
What You Will Learn
- Why a webhook delivery is a durable state machine rather than a single HTTP POST
- How exponential backoff spreads eight retry attempts across roughly 27 hours
- Why every non-2xx response is retried, 4xx included, and what each status tells you
- Why a timeout is the ambiguous case that makes idempotency mandatory
- How HMAC-SHA256 webhook signatures are built over the id, timestamp and raw body
- Why verifying a re-serialized JSON body always fails, and what to do instead
- How a timestamp tolerance window limits replay attacks
- How receivers deduplicate deliveries using a message ID that is stable across retries
Topics covered: webhooks, http, retries, idempotency, hmac, signatures, api, reliability, educational, interactive
// simulator
Webhook Delivery Simulator
Send a webhook through a production-style delivery flow. Change endpoint responses, watch retries and backoff, inspect real HMAC-SHA256 signatures, and redeliver the same message to see receiver-side deduplication.
Delivery path
Follow one message from your app to the receiver.
invoice.paid
Durable message
ID + time + body
Intermittent
Waiting for a delivery
Retry schedule
Start with Intermittent to watch two failures recover on the third attempt.
About this webhook delivery simulator
1. Persist and retry
A delivery must survive a restart. Retry every timeout and every non-2xx response with backoff. A 4xx keeps failing until the receiver is fixed, so it runs out the schedule.
2. Verify raw bytes
The signature covers the message ID, timestamp, and raw body. Verify before parsing so whitespace or serialization changes cannot invalidate an authentic request.
3. Deduplicate
Delivery is at-least-once. Store the stable message ID with the business update in one transaction, then return 200 when the same message arrives again.
From simulator to production
The production webhook delivery guide turns this flow into a typed sender and receiver you can build from. This simulator uses the published Svix retry rules (eight attempts over about 27 hours, a 15 second timeout, and a retry for any non-2xx response) and genuine Standard Webhooks signatures. For the underlying queue and throttling concepts, try the message queue simulator and rate limit simulator.
Overview
A webhook is an HTTP request your system sends to someone else when an event happens, and delivering it reliably is harder than sending it once. This simulator models the delivery of sample events, such as invoice.paid or deployment.succeeded, to an endpoint whose behavior you choose: it can answer 200, fail intermittently, return a 500, time out, rate limit you with a 429 or reject the request with a 400. You can watch failed deliveries retry on a growing schedule until a 2xx response arrives or the attempts run out, the way Svix does it. The payloads are signed with real HMAC-SHA256, and you can tamper with a delivery by editing the body, using the wrong secret or replaying it later, then see verification catch each case. Together these show the three habits of a dependable webhook system: persist the event and retry with backoff, verify the signature over the raw bytes before parsing, and deduplicate on the receiving side because retries mean the same event can arrive more than once.
Try this
- Compare "Intermittent", which succeeds after a couple of failures, with "500 error" and "400 bad request", which keep retrying until the attempts are exhausted.
- Switch the tampering option to "Edit body" or "Wrong secret" and watch signature verification reject the delivery.
- Try "Replay later" to see why a timestamp check matters even when the signature itself is valid.
Frequently asked questions
- Which webhook responses should be retried?
- Timeouts, connection errors, 5xx responses and 429 rate limits are usually temporary and always worth retrying with backoff. Senders differ on other 4xx codes: services such as Svix retry every non-2xx response until the attempts run out, while some treat a 400 as permanent.
- How do webhook signatures work?
- The sender computes an HMAC, commonly HMAC-SHA256, over the raw request body (often with a timestamp) using a shared secret, and sends it in a header. The receiver recomputes it over the exact bytes it received and compares the two.
- Why must webhook handlers be idempotent?
- Because retries mean the same event can be delivered more than once. Recording the event id and skipping ids you have already processed keeps a duplicate from charging, emailing or deploying twice.
Try next
// simulator
Preview Environment Simulator
See how a pull request becomes a temporary copy of your app, complete with a private URL, safe test data, review checks, and automatic cleanup.
// game
Heroku-Style Name Generator
Generate names the way Heroku, Docker, Kubernetes, and petname do, see how the word lists combine, and learn when the birthday problem makes random names collide.
// simulator
How Docker Works Under the Hood
Watch what really happens when you run docker run -p 8080:80 nginx, one layer at a time. Step down the whole stack: the CLI, the daemon, the registry pull, containerd, the OCI runtime bundle, runc, the running container, and the shared Linux kernel. Every stage shows the real low-level command you can run yourself, so it doubles as a tour of the primitives that make a container: namespaces, cgroups, and runc. A container is not a small VM, and this shows you why.