Webhooks vs. Polling: Choosing How Your Integration Detects Changes

Every integration must answer a basic question: how do we find out that something changed? There are two answers — be told (webhooks) or ask (polling). This comparison is platform-neutral; for a Shopify-specific implementation of the combined approach, see Shopify webhooks vs. polling for ERP integrations.

How each works

Webhooks: the source system sends an HTTP request to your endpoint when an event occurs. Your endpoint verifies and stores the event, and your integration processes it.

Polling: your integration periodically queries the source system for records changed since the last check, typically using a modification timestamp, sequence number, or change log.

Comparison table

Dimension	Webhooks	Polling
Latency	Seconds	Up to one interval
Completeness	Depends on platform delivery guarantees and your receiver’s uptime	Complete for the window queried, given correct checkpoint logic
API usage	Low; one fetch per change if needed	Constant; scales with frequency
Infrastructure	Public endpoint (or managed event bus), signature verification	Scheduler only
Ordering	Often not guaranteed	Controlled by your query sort order
Duplicates	Possible	Possible with overlapping windows
Behavior during your outage	Platform retries for a limited period; may disable the subscription	Next run catches up
Behavior during source outage	No events sent	Polls fail; retry next interval
Payload content	Varies: full resource or only an ID	Whatever you query

What platforms document about webhook delivery

Delivery semantics differ, and they matter:

• Shopify documents a five-second response limit, up to eight retries over four hours, subscription removal after persistent failures, no ordering guarantee, and recommends reconciliation jobs.
• WooCommerce documents that a webhook is disabled after five consecutive failed deliveries.
• BigCommerce documents lightweight payloads, occasional duplicates, domain-level blocklisting when the success ratio drops, and retries for a little over 48 hours.
• Adobe Commerce offers Adobe I/O Events for asynchronous events and a separate webhooks module for synchronous calls.

In every case, webhooks are a best-effort fast path that your design must back up.

When webhooks alone can be enough

• The data is low-stakes (for example, analytics or marketing tags) and occasional gaps are acceptable.
• The source offers durable delivery to a managed queue or event bus with long retention and replay.
• A human process already reconciles the data.

When polling alone can be enough

• The source has no webhooks.
• The target processes in batches anyway (an ERP that imports orders hourly).
• You want to avoid exposing a public endpoint.
• Volume is low and rate limits are generous.

When to combine them

For order export, inventory, and fulfillment — flows where a missed event costs money — combine both:

1. Webhooks trigger fast processing.
2. A scheduled poll queries changes since a checkpoint and enqueues anything not yet processed.
3. Both paths feed one idempotent queue.
4. Workers fetch current state before writing, so ordering and duplicates do not matter.

This hybrid gives near-real-time behavior in normal conditions and guaranteed catch-up after failures.

Design tips for each approach

Webhooks

• Verify signatures or authentication headers before any processing.
• Store first, respond quickly, process asynchronously.
• Deduplicate by delivery ID and process idempotently.
• Monitor subscription health and delivery failures.

Polling

• Query by modification time with an overlap window.
• Advance the checkpoint only after the batch succeeds.
• Request only identifiers in the poll; fetch details in workers.
• Respect rate limits and schedule heavy polls off-peak.

Summary

Webhooks win on latency and efficiency; polling wins on predictability and simplicity. Their failure modes are complementary, which is why the most dependable ecommerce–ERP integrations use webhooks for speed and polling for completeness, feeding a single idempotent pipeline.