A webhook is a way for one system to tell another system that something just happened. When a client pays an invoice in Stripe, Stripe immediately sends a message to a URL you configured saying the payment just happened, with all the details. Your system receives that message and does whatever it needs to do with it.

How are webhooks different from polling?

Polling means your system sends a request to another system repeatedly on a schedule asking if anything changed. Most of the time the answer is no and those requests are wasted. Webhooks are push-based: the other system sends you a message the moment something happens. You only receive data when it actually matters.

Why do webhooks sometimes deliver duplicate events?

Webhooks are delivered at least once, not exactly once. If your server is down, your handler times out, or the 200 OK response gets lost in transit, the webhook provider will retry. This means you can receive the same event multiple times. Your system must be built to handle duplicates using idempotency.

How do you verify that a webhook request is genuine?

Use HMAC-SHA256 signature verification. The webhook provider gives you a signing secret. When they send a webhook, they compute an HMAC-SHA256 signature using the raw payload and the secret, and include it in a request header. You perform the same computation and compare results using a timing-safe comparison to confirm the request is genuine and has not been tampered with.

What is idempotency in webhooks?

Idempotency means running the same operation multiple times produces the same result as running it once. For webhooks, you implement this by storing the unique event ID of each webhook you process. When a duplicate arrives, you check if that event ID has already been processed and skip it if so, preventing double-charges, duplicate emails, and corrupted records.

Why should webhook processing happen in a queue?

Your webhook endpoint should do almost no real work. Verify the signature, check idempotency, acknowledge receipt with a 200, then stop. The actual processing should happen in a queue asynchronously after the HTTP response has been sent. This prevents timeouts from the webhook provider and handles burst traffic without overwhelming downstream APIs.

Webhooks Explained the Way Nobody Explains Them

May 17, 2026 · ~16 min read · by Abhiman

Please enable JavaScript to read this article.

← Back to Blog