Thuta Learning
IntermediateWeb Developmentintermediate

Webhook vs Polling

What you'll walk away with

  • Explain the core ideas behind Webhook vs Polling
  • Read the diagram and trace how a request, response, or event flows through the system
  • Explain how this applies to a real API integration you might build

Build the mental model

Polling and webhooks solve the same problem — finding out something changed — with opposite mechanics. Polling repeatedly asks if anything happened; a webhook sends you a request the instant it does.

Polling is simple and needs no public endpoint, but wastes requests and adds delay. A webhook is near-instant and wastes nothing, but requires a public URL and inherits signature verification and idempotent handling as real requirements.

AspectComparison
LatencyPolling: delay up to one interval. Webhook: near-instant, no meaningful delay.
EfficiencyPolling: wastes requests when nothing changed. Webhook: one request per real event, nothing wasted.
ComplexityPolling: simple, no public endpoint needed. Webhook: needs signature verification and idempotent handling.
RequirementsPolling: only an outbound network connection. Webhook: a publicly reachable server endpoint.

Polling fits low-frequency checks or environments where you can't host a public endpoint. Webhooks fit anywhere near-real-time matters and you can host a receiving endpoint.

text
POLLING VS WEBHOOK
------------------
-----
Polling (your app asks repeatedly):
  Your App -> "anything new?" -> Server   (t=0s)
  Your App -> "anything new?" -> Server   (t=10s)
  Your App -> "anything new?" -> Server   (t=20s)
  Your App -> "anything new?" -> Server   (t=30s)

Webhook (service pushes once, when it happens):
  External Service -> "something happened!" -> Your App (t=7s)

Connect it to a real scenario

The code below simulates both approaches against the same timeline of two events at seconds 7 and 23, over a 30-second window. simulateWebhook notices instantly with no interval to wait out.

Run both functions and compare totalRequests and delay. Polling makes a fixed number of requests with delay depending on timing luck. The webhook makes exactly one request per event with zero delay every time.

Scale the polling interval down to notice sooner, and you immediately pay for it in far more requests — a tradeoff webhooks sidestep entirely.

Try the working example

javascript
function simulatePolling(events, intervalSeconds, totalSeconds) {
  let requests = 0;
  const noticedAt = [];
  for (let t = 0; t <= totalSeconds; t += intervalSeconds) {
    requests++;
    events.forEach((e) => {
      if (e.at <= t && e.noticedAtPoll === undefined) {
        e.noticedAtPoll = t;
        noticedAt.push({ event: e.name, occurredAt: e.at, noticedAt: t, delaySeconds: t - e.at });
      }
    });
  }
  return { approach: "polling", totalRequests: requests, noticedAt };
}

function simulateWebhook(events) {
  const noticedAt = events.map((e) => ({ event: e.name, occurredAt: e.at, noticedAt: e.at, delaySeconds: 0 }));
  return { approach: "webhook", totalRequests: events.length, noticedAt };
}

const timeline = [
  { name: "payment.completed", at: 7 },
  { name: "user.created", at: 23 }
];

const pollingResult = simulatePolling(timeline.map((e) => ({ ...e })), 10, 30);
const webhookResult = simulateWebhook(timeline);

console.log(pollingResult);
console.log(webhookResult);
You should see
{
  approach: 'polling',
  totalRequests: 4,
  noticedAt: [
    { event: 'payment.completed', occurredAt: 7, noticedAt: 10, delaySeconds: 3 },
    { event: 'user.created', occurredAt: 23, noticedAt: 30, delaySeconds: 7 }
  ]
}
{
  approach: 'webhook',
  totalRequests: 2,
  noticedAt: [
    { event: 'payment.completed', occurredAt: 7, noticedAt: 7, delaySeconds: 0 },
    { event: 'user.created', occurredAt: 23, noticedAt: 23, delaySeconds: 0 }
  ]
}

5-minute try-it

Add a third event to the timeline at second 15 and re-run both simulations — predict the new totalRequests and delay before checking the output.

One important caution

Choosing webhooks for a system that can never expose a publicly reachable server, making delivery impossible.

Choosing polling for a high-frequency, time-sensitive use case and accepting an unnecessary delay and wasted request volume.

Polling (computer science) — WikipediaAPI Integration & Webhooks

Easy traps

  • Choosing webhooks for a system that can never expose a publicly reachable server, making delivery impossible.
  • Choosing polling for a high-frequency, time-sensitive use case and accepting an unnecessary delay and wasted request volume.
  • If you haven't taken the API Tutorial yet, it's worth finishing that first -- this course doesn't re-teach REST/HTTP/auth basics, it builds on top of them with webhooks, testing, reliability, and integration architecture.

Exercise

Add a third event to the timeline at second 15 and re-run both simulations — predict the new totalRequests and delay before checking the output.

You'll know it worked when: { approach: 'polling', totalRequests: 4, noticedAt: [ { event: 'payment.completed', occurredAt: 7, noticedAt: 10, delaySeconds: 3 }, { event: 'user.created', occurredAt: 23, noticedAt: 30, delaySeconds: 7 } ] } { approach: 'webhook', totalRequests: 2, noticedAt: [ { event: 'payment.completed', occurredAt: 7, noticedAt: 7, delaySeconds: 0 }, { event: 'user.created', occurredAt: 23, noticedAt: 23, delaySeconds: 0 } ] }

Webhook vs Polling | Thuta Learning