Polling versus webhook is the basic decision behind how an automation finds out that something has happened. With polling, your system asks the source on a schedule: ‘anything new yet?’. With a webhook, the source sends a message the instant the event occurs, so your system reacts straight away.
A simple way to picture it: polling is checking your mailbox every hour to see if a parcel arrived. A webhook is the courier ringing your doorbell the second they drop it off. The doorbell is faster and you never check for nothing, but it only works if the courier actually has a bell to ring. If the source system offers no webhooks, polling is your only option.
The trade-offs run deeper than speed. Polling wastes most of its requests, since 99 out of 100 checks return “nothing new”, and hitting an API every minute can burn through rate limits or cost you money per call. A webhook fires only when there is real news, so it scales better. But it needs a public endpoint that is always up, and if your server is down for two minutes when the webhook arrives, that event is simply gone unless the source retries.
In practice the rule of thumb is straightforward. Need real-time and the source supports it? Use a webhook. Source cannot push, or a few minutes of delay is fine? Polling is simpler and perfectly reliable. Stripe, GitHub and Shopify all send webhooks, while many older internal systems only let you poll. Many real setups use both: a webhook for speed with a periodic polling sweep as a fallback in case a notification is ever missed.
At TopDevs we default to webhooks for speed and fall back to polling when a system cannot push, often combining the two so nothing slips through.
