Webhooks vs polling

Published 18 October 2026

You are waiting for a courier. Polling is calling the courier company every ten minutes to ask "has it left yet?". A webhook is giving them your number and asking them to call you when it leaves. The second is obviously better, until the phone is switched off when they call, or they call twice, or someone else rings pretending to be the courier.

Between services, a webhook is an HTTP POST that a provider sends to a URL you registered, when an event happens on their side: Razorpay telling you a payment succeeded, GitHub telling you someone pushed, Shopify telling you an order was placed.

What polling costs#

Polling is simple and in your control, and it is wasteful in exact proportion to how rarely things change.

Webhooks, and the five rules for receiving them#

A webhook is efficient and immediate. It is also an incoming request from the internet that affects your money, arriving at least once, possibly out of order, and possibly not at all if your endpoint was down long enough. Receiving them correctly means five habits.

1. Verify the signature on the raw request body with the shared secret, using a constant time compare. Check the timestamp included in the signature (Stripe's Stripe-Signature header has one) and reject old ones, so a captured request cannot be replayed later.
2. Acknowledge fast, process later. Return 2xx as soon as the event is safely stored or queued. Slow handlers cause timeouts, and timeouts cause retries.
3. Deduplicate by event id. Providers retry on any failure or timeout, so the same event can arrive twice. See delivery guarantees.
4. Do not trust order. "payment.refunded" can arrive before "payment.captured". Either compare timestamps or versions, or fetch the object's current state from the API when an event arrives.
5. Reconcile. If your endpoint was down for longer than the provider retries (Stripe retries for up to three days, others less), events are lost. A periodic job that lists recent objects from the API and fixes any mismatch is the safety net. Webhooks for speed, polling for correctness.

import { createHmac, timingSafeEqual } from 'node:crypto'
 
// Use the raw body bytes, exactly as received. Parsing and re-serialising
// JSON changes whitespace and breaks the signature.
export function verify(rawBody: Buffer, header: string, secret: string) {
  const expected = createHmac('sha256', secret).update(rawBody).digest('hex')
  const a = Buffer.from(expected)
  const b = Buffer.from(header)
  return a.length === b.length && timingSafeEqual(a, b)
}

Sending webhooks#

If you are the provider, the mirror image applies: sign every payload with a per customer secret and include a timestamp; send from a queue with retries and exponential backoff over hours or days; give each event a unique id; let customers see delivery attempts and replay events from a dashboard; disable endpoints that fail for days and email the owner. And do not let one customer's slow endpoint hold up everyone else's deliveries: isolate per customer queues or concurrency.

In the interview#

Checkpoint#