Webhooks or scheduled polling — which should we use to keep systems in sync?
Both, for different reasons. Webhooks give you low latency and are the right trigger for anything time-sensitive like routing a new request. Polling gives you correctness, because webhooks get missed, duplicated and delivered out of order. The standard design is webhooks for speed plus a scheduled reconciliation pull that repairs whatever the event stream lost. Relying on either alone is how integrations drift.
What each one is actually good at
A webhook is a notification. It tells you something happened moments after it did, which is exactly what you want when a new request should trigger a text message or a routing decision. It is a poor foundation for a ledger, because you only learn about events the sender successfully delivered.
A scheduled pull is a census. It asks the platform what the current state is, which makes it authoritative and slow. Using it for anything that needs to happen within seconds means running it constantly, which rate limits will not tolerate.
The three failures you must design for
- Duplicates. The same event arrives twice. Every handler must be idempotent — processing the same event a second time must change nothing.
- Out-of-order delivery. A status update can arrive before the creation event. Handlers should reconcile against current state rather than assuming sequence.
- Silent loss. Your endpoint was down for four minutes, or the sender gave up after retries. Nothing errors. You simply never hear about those records again.
The reconciliation sweep
The repair mechanism is a periodic pull of everything modified in a recent window — the last day, say — compared against what you have. Anything missing gets filled in. Anything different gets corrected. Run it on a schedule that matches how much drift you can tolerate.
Log what the sweep repairs. A rising repair count is an early warning that something upstream changed, and it is far better to learn that from a log than from an owner noticing a revenue number looks wrong.
Practical rules for the endpoint
Verify signatures if the platform provides them. Respond fast and process asynchronously — a webhook receiver that does work inline will time out and cause retries, which causes duplicates, which causes the problems above. Store the raw payload before you parse it, so a mapping bug can be replayed rather than re-requested.
None of this is exotic, but it is the difference between an integration that survives a platform's release schedule and one that needs attention every few weeks. It is the baseline we apply in API integration work, and it is why operational AI built on top can be trusted to act on the data rather than just display it.
Topics: webhooks · polling · sync · integration architecture
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.