Most integration briefs we see already contain the answer before anyone has looked at the problem: “it should use webhooks, that’s the modern way.” Sometimes that’s correct. Often it isn’t. The choice between webhooks and polling is not a matter of taste or trend, it’s a question of what the third-party system actually guarantees, what happens when a message goes missing, and how much operational complexity your team is willing to own. Get it wrong and you either build infrastructure you didn’t need or ship an integration that quietly drops events for weeks before anyone notices.
What each pattern actually commits you to
Polling means your system asks a question on a schedule: “anything new since last time?” It’s simple, it’s entirely under your control, and every failure mode reduces to “the next poll will pick it up.” The cost is latency (you’re only ever as fresh as your polling interval) and, at scale, wasted requests when nothing has changed.
Webhooks invert that: the third party pushes an event to an endpoint you expose the moment something happens. Latency drops to seconds, and you stop paying for empty polls. In exchange, you take on a list of responsibilities that rarely make it into the first conversation about the project: verifying the payload actually came from the vendor, handling duplicate deliveries, handling out-of-order deliveries, deciding what happens when your endpoint is down for ten minutes during a deploy, and giving someone a public HTTPS endpoint to defend.
Why webhooks aren’t automatically the upgrade
A webhook is a promise made by someone else’s infrastructure, and promises vary in quality. Before treating webhooks as the default, it’s worth checking what the vendor actually guarantees:
- Do they sign the payload, so you can verify it wasn’t forged or replayed by someone else?
- Do they retry on failure, and for how long? Some vendors give up after three attempts over a few minutes; others retry for 24 hours.
- Is delivery at-least-once or at-most-once? At-least-once is far more common, which means your handler has to be idempotent or you’ll process the same event twice.
- Is there an events or activity log you can query to catch anything your endpoint missed? Without one, a missed webhook is simply gone.
- Do events arrive in order, and does your logic assume they do? A “subscription cancelled” event arriving before “subscription created” will break naive handlers.
None of these are exotic edge cases. They’re the normal behaviour of webhook systems, and each one is engineering work: signature verification middleware, a deduplication table keyed on event ID, a dead-letter queue for events your handler couldn’t process, monitoring that tells you when your endpoint has been silently failing. A webhook integration that skips this is not simpler than polling, it’s just broken in a way that hasn’t surfaced yet.
When polling is the correct answer, not the fallback
Polling deserves more respect than it usually gets in vendor pitches. It’s the right fit when:
- The third party doesn’t offer webhooks at all. Plenty of ERPs, legacy finance systems and internal line-of-business tools don’t, and building a webhook relay on top of a system that was never designed to push events adds a layer of fragility for no real gain.
- Near-real-time isn’t actually a requirement, it’s an assumption. If the business process downstream only checks the data once an hour anyway, sub-second delivery is solving a problem nobody has.
- You’d rather not expose a public inbound endpoint. For internal tools or anything sitting behind a firewall by design, polling out is a much smaller attack surface than accepting arbitrary inbound requests.
- You need a straightforward mental model for a small team. “We ask every five minutes” is something anyone on the team can reason about at 2am. “We depend on their retry policy, our signature verification, and our dedup table all working correctly together” is not.
The trade-off is cost and rate limits at volume. Polling a thousand accounts every minute against an API with a strict quota will hit limits fast, and there’s no way to poll your way to sub-minute latency without a lot of requests. If the integration needs to scale past a modest number of accounts or a tight latency target, that ceiling shows up quickly.
The pattern most production systems actually end up with
In practice, the systems we’d trust with business-critical data rarely pick one pattern outright. They use webhooks as the trigger for speed, and a periodic reconciliation poll as the safety net: once an hour, or once a day, ask the source system for everything that changed in that window and diff it against what you have. If the webhook fired correctly, the poll finds nothing and costs almost nothing. If a webhook was missed, dropped, or arrived while your endpoint was mid-deploy, the reconciliation poll catches it before it becomes a support ticket.
This costs more to build than either pattern alone, which is exactly why it’s worth reserving for the integrations where being wrong is expensive: payment status, stock levels, anything feeding a compliance record. A webhook-only integration for a low-stakes, cosmetic sync (say, updating a display name) usually isn’t worth the extra reconciliation logic.
The question worth asking before any integration ticket is written isn’t “webhooks or polling”, it’s “what does it cost us if this specific piece of data is six hours late, and what does it cost us if it’s silently wrong?” The answer to that decides the pattern, and often decides that you need both.
Questions to settle before the integration is scoped
A short checklist we go through before committing to a pattern:
- Does the vendor support webhooks at all, and do they publish a retry policy and an events log?
- Is there a genuine business reason for near-real-time delivery, or would a five-minute or hourly cadence go unnoticed?
- What’s the actual cost of a missed or duplicated event for this specific piece of data, in money, compliance risk or customer trust?
- Who owns the public endpoint’s security, and does the team have the operational maturity to run signature verification, idempotency and dead-letter handling properly?
- What are the vendor’s rate limits, and do they make polling at the required frequency viable or not?
If you can’t answer the second and third questions with confidence, that’s the actual scoping gap, not the choice of pattern. Everything else follows from those answers.