Blog
3 min read

Webhooks vs Polling: How Apps Find Out Something Changed

Polling means asking 'anything new?' on a timer; a webhook means the other service tells you when something happens. How each works, their costs and failure modes, when polling is actually the better choice, and how to combine them reliably.

Your app often needs to know when something happens somewhere else: a payment succeeded on Stripe, a file finished processing, a new order arrived. There are two basic ways to find out.

Polling: keep asking

Your app asks the other service, on a schedule, "anything new?"

setInterval(async () => {
  const res = await fetch('https://api.example.com/jobs/123')
  const job = await res.json()
  if (job.status === 'done') handleDone(job)
}, 5000)

Like refreshing your inbox every few seconds.

Webhooks: get told

You give the other service a URL. When something happens, it sends a request to your URL with the details. (What is a webhook?)

app.post('/webhooks/payments', express.raw({ type: 'application/json' }), (req, res) => {
  // verify the signature first!
  const event = JSON.parse(req.body)
  if (event.type === 'payment.succeeded') markOrderPaid(event.data)
  res.sendStatus(200)
})

Like getting a notification instead of checking.

Side by side

Polling Webhooks
Who starts it Your app The other service
How fast you find out Up to one interval late Almost immediately
Wasted requests Many ("nothing new") None
Needs a public URL No Yes
Works on localhost Yes Needs a tunnel (test webhooks locally)
Security You call them with your key You must verify they're real
If your app is down You catch up when it's back Events may be retried, or missed
Complexity Simple More moving parts

When polling is the better choice

  • The other service doesn't offer webhooks.
  • Your app isn't reachable from the internet (a script on your laptop, a device behind a firewall).
  • You only need to check occasionally — once an hour, once a day.
  • You're waiting on one short job — poll every few seconds until it's done, then stop.

Polling is simpler and harder to get subtly wrong.

When webhooks are the better choice

  • You need to react quickly (payments, messages, deployments).
  • Events are frequent or unpredictable.
  • Polling would mean thousands of wasted requests — and you may hit rate limits. (What is rate limiting?)

Webhook pitfalls

  1. Verify the signature. Anyone can send a request to your webhook URL. Services like Stripe sign each webhook; check it, or an attacker can fake "payment succeeded". (Handling webhooks reliably)
  2. Expect duplicates. Services retry if you don't answer quickly, so the same event can arrive twice. Make handling it twice harmless. (Idempotency keys)
  3. Expect them out of order.
  4. Respond fast. Acknowledge with a 200 straight away and do slow work in a background job. (Background jobs)
  5. You might miss some. If your server was down longer than the retry window, events are lost.

The reliable pattern: both

Production systems often combine them: webhooks for speed, a periodic poll as a safety net. Every hour or so, ask the API for anything changed recently and reconcile. You get near-instant updates, and nothing falls through the cracks.

What about WebSockets?

Webhooks are server-to-server. To push updates from your server to a user's browser in real time, you'd use WebSockets or server-sent events instead. (What are WebSockets?, SSE vs WebSockets)

The summary

  • Polling: you ask repeatedly. Simple, a bit slow, wasteful at scale.
  • Webhooks: they tell you. Fast and efficient, needs a public URL and care.
  • Verify signatures, handle duplicates, respond quickly.
  • For reliability, use webhooks plus an occasional reconciliation poll.

EasySpawn gives your app a permanent public HTTPS address — exactly what webhooks need — plus background workers for processing them. See how it works or join the waitlist.

Related: What Is a Webhook? · Handling Webhooks Reliably · How to Test Webhooks Locally · Your App Needs Background Jobs

Keep reading