Backend & Data
Webhooks vs polling: don't call us, we'll call you
Your app needs to know when a payment clears, an order fills, or a file finishes processing. You have two options: poll (keep asking "is it done yet?") or use a webhook (get pinged the moment it happens). It's the difference between refreshing your inbox and hearing the notification chime.
Polling: are we there yet?
Polling is the simple one: on a schedule, you ask the server "anything new?" Most of the time the answer is "no." It works, and sometimes it's the only option — but it's wasteful (lots of empty checks) and laggy (you only learn about an event at the next check, not when it happened). Poll too often and you burn resources; poll too rarely and you're always a bit behind.
Webhooks: the doorbell
A webhook flips the direction. You register a URL with the other service, and when the event happens it sends an HTTP POST straight to you. No repeated asking, no lag — the news arrives exactly when it's news. The cost is that you now have to run a public endpoint that's always ready to receive.
Polling: you keep phoning to ask. Webhook: you leave your number and they call you when it happens.
What webhooks ask of you
- A public endpoint that's up and fast — the sender expects a quick
200, so do heavy work afterwards, not inline. - Verify the sender. Anyone can POST to a public URL, so real webhooks are signed — check the signature before trusting the payload.
- Expect retries and duplicates. If your endpoint hiccups, good senders retry — which means the same event can arrive twice. Handle it idempotently.
Rule of thumb: if you need to know the instant something happens and the other side supports webhooks, take the webhook. Fall back to polling when you can't run an endpoint or the source only offers a "check here" API.