Polling versus webhooks

What is polling versus webhooks?

Polling and webhooks are the two ways your system can find out that something happened somewhere else. With polling you ask: every few minutes your integration calls the other system and checks whether anything changed since the last time. With a webhook the other system calls you, sending a short message to a URL you registered, the moment the event fires.

The only real difference is who starts the call, and everything else follows from that: how long you wait for the news, how many API requests you burn getting it, and which side carries the work of making sure nothing goes missing.

Polling is phoning your supplier every morning to ask whether your order shipped. A webhook is the supplier phoning you the moment it does.

How each one works

A polling integration keeps a bookmark: the timestamp of the last change it saw, or the id of the last record it read. Each run it asks the API for everything after that mark and moves the mark forward. Power Automate polling triggers work this way, and Microsoft describes them as setting a state, checking for updates over an interval, and requesting all the new data since that state. Getting the mark right is most of the work, because an incrementing id never shows you an update to an older record, so you usually filter on a last-modified column instead.

A webhook needs none of that. You register one URL with the source, pick the events you want, and from then on the source sends an HTTP POST with a small payload whenever one fires. No empty requests, and the delay is seconds instead of the length of an interval. What you give up is the safety of asking again: a polling run you miss costs nothing because the next one picks up everything since the mark, while an event your endpoint did not accept is gone as soon as the sender stops retrying.

What a webhook receiver has to handle

A webhook URL sits open on the internet and anyone who finds it can post to it, so the receiver carries obligations a polling job never has.

1. Verify the signature before you trust a single field. Stripe signs every delivery in the Stripe-Signature header, GitHub does the same in X-Hub-Signature-256. Check against the raw request body, not a re-serialised copy.

2. Answer fast, do the work after. GitHub expects a 2XX within ten seconds, and Stripe tells you to return a 2xx before any logic that could time out. The endpoint writes the payload to a queue, returns 200, and a background worker takes it from there.

3. Deduplicate on the event id. The same event can land twice, usually because your 200 got lost on the way back, so Stripe advises logging the ids you have processed and skipping the ones you recognise. Order is not guaranteed either, so when it matters, fetch the current state of the object over the API rather than rebuilding it from events.

4. Give failures somewhere to go. A worker that cannot process a payload retries with growing pauses, then parks the raw message in a dead-letter queue, so one broken order does not block the rest.

5. Poll anyway, as a safety net. Shopify is blunt about this: your app should not rely on receiving data from webhooks, and should run reconciliation jobs that periodically fetch data from the API so it stays consistent.

Order status from your webshop into your ERP

Take a shop doing 40 orders a day that have to land in the ERP so the warehouse can pick them. Poll the orders API every five minutes and you make 288 calls a day, of which roughly 250 come back empty, and an order waits two and a half minutes on average, five at worst. An hourly poll costs 24 calls but pushes that wait to half an hour. A poller that is down all morning loses nothing: the run at noon collects every order since the mark.

With a webhook the shop sends 40 deliveries a day and the ERP knows within seconds, but you need an endpoint reachable from the internet, signature checking, deduplication, and an answer for the morning your ERP is down for maintenance and twelve orders get pushed at a URL returning 503. What most shops end up with is both: the webhook does the day-to-day work, and a job at night asks the shop for every order of the last 48 hours and creates the ones the ERP never received.

How do you choose?

You can skip the architecture discussion by asking one question: what does it cost you if you find out about this event ten minutes late? For a payment that releases a download, ten minutes is a support ticket. For a website lead that has to reach a sales rep while the prospect is still interested, ten minutes is the difference between a conversation and a voicemail. For an accounting export, it is nothing at all.

Two practical limits narrow it further. A source that charges per API call or enforces a tight rate limit makes a short polling interval expensive, so the webhook pays for itself. And if the receiving system has no public HTTPS address, a laptop or a server behind a firewall, polling is the option that works at all, because the call goes out from your side rather than in.

What to watch out for with polling and webhooks

Plenty of systems offer neither
Older ERPs, sector-specific packages and most on-premises software have no event notification and no API worth using. Then you drop a layer: a trigger on the database that writes changes to an outbox table you read, a scheduled export dropped as a file in a folder, or Change Data Capture reading the transaction log.

Not every set of vendor webhooks is worth trusting
Webhooks are not standardised. No IETF standard covers them, and the nearest thing is Standard Webhooks, a community specification backed by people from Zapier, Twilio, ngrok and Kong, whose own opening line admits that every provider implements webhooks differently and with varying quality. Stripe retries a failed delivery for up to three days with growing pauses; other vendors try once and keep no delivery log at all. Read that policy first, and where there is none, treat the webhook as a hint and let the reconciliation poll decide what is true.