Shopify webhooks vs API polling: why webhooks win for OMS sync

A merchant integrating Shopify with their Order Management System (OMS) needs every new order synced to the OMS for fulfillment. The integration approach determines latency, cost, and the on-call experience.

Two options show up in discussion. Webhooks win for three specific reasons - and the third reason is usually what pushes teams to pick webhooks after they've tried polling.

The options

API polling. An integration runs on a schedule (every 5 minutes, say). It calls Shopify's Orders API, asks "what orders have been created since my last call", writes those to the OMS.

Webhooks. Shopify calls the integration when events happen. Orders/create event fires within seconds of the order being placed; the integration receives the order payload and forwards to the OMS.

Reason 1: Latency

Polling has inherent latency equal to the polling interval. A 5-minute cycle means orders wait up to 5 minutes for OMS sync. For fast-moving operations (shipping same-day, cross-docking), 5 minutes is already too long.

Webhooks deliver within seconds. Shopify fires the webhook as soon as the order commits; the integration's response time dominates end-to-end latency. For most OMS integrations, sub-10-second delivery is achievable.

If the merchant's fulfillment process ships within 2 hours of order, a 5-minute polling gap already consumes 4% of that window. Webhooks put that back.

Reason 2: API rate-limit pressure

Every poll cycle hits the Shopify Admin API. Even if no new orders exist, the poll still costs an API call (and GraphQL cost). Over a year of polling every 5 minutes, that's over 100k calls just to ask "anything new?".

Shopify apps share a rate-limit budget. Polling consumes budget whether orders exist or not. Webhooks don't count against the API budget at all - they're Shopify calling out, not the app calling in.

For merchants with multiple integrations (OMS, analytics, email, fulfillment carrier), every polling integration compounds the problem. Webhook-based integrations free up budget for genuine on-demand API work.

Reason 3: Resilience and gap handling

This is the reason teams switch to webhooks after the first polling outage.

Polling's failure modes:

• Poller goes down for 4 hours → backfill from the last 4 hours of orders when it restarts
• Poller's "last cursor" state gets lost (server rebuild, DB corruption) → duplicate ingestion or missed orders
• Shopify API rate-limited during peak → poller falls behind, orders delay

Webhook failure modes:

• Endpoint returns 5xx → Shopify retries with backoff (up to 19 retries over 48 hours)
• Endpoint returns 4xx (auth error, bad payload) → Shopify gives up faster; integration alerted
• Webhook fires before endpoint is ready → Shopify's retry buffer absorbs

Shopify's webhook retry behavior is the critical piece. A temporary integration outage doesn't lose events - Shopify holds and retries. The integration only needs to be eventually available within the retry window.

When polling still fits

Not every integration belongs in webhook mode:

• Bulk historical export - catching up on 10,000 existing orders. Use Admin API pagination, not webhooks.
• Scheduled reconciliation - nightly "are our counts right?" cross-check. Polling fits this naturally.
• Aggregation queries - "give me daily revenue" doesn't fit the webhook event model.

Webhooks are for event-driven updates (something happened, I want to know now). Polling is for scheduled batch work.

Webhook setup

Configure via Admin API:

Variables:

Or in the Shopify admin UI for simple setups. For app-distributed webhooks, subscribe programmatically at app install so every merchant gets the same event wiring.

Verifying webhook authenticity

Every webhook includes an HMAC signature header. The receiving endpoint must verify:

Without this check, anyone who guesses the endpoint URL can post fake orders. Verification is non-negotiable.

Idempotency

Shopify may retry a webhook. The receiver should be idempotent - processing the same webhook twice shouldn't create two orders in the OMS.

Standard pattern: extract the order ID from the payload, check if OMS already has that order, skip if yes. The deduplication key is the combination of Shopify order ID and webhook topic.

Error handling on the receiver

The endpoint needs to:

• Return 200 fast (< 5 seconds) on successful receipt
• Queue the work for async processing (don't do OMS integration synchronously inside the webhook response)
• Return 5xx to trigger retry if truly failing
• Log webhook receipt for debugging

Common bug: returning 200 but silently failing to queue the work. Shopify thinks the webhook was delivered; the OMS never gets the order. The fix is acknowledging only after successful queue insertion.

What ships with webhook-based OMS integration

A production OMS integration using webhooks has:

• Webhook subscriptions for orders/create, orders/updated, orders/paid, refunds/create
• HMAC verification on every incoming webhook
• Idempotent processing keyed on order ID + event type
• Queue-based architecture (webhook accepts fast, worker processes async)
• Monitoring on webhook receipt rate and processing lag
• Periodic reconciliation poll as a safety net (daily cross-check)
• Runbook for when webhooks fall behind (backfill via Admin API)

The daily reconciliation is worth calling out. Even with webhooks as the primary mechanism, a nightly comparison of "orders in Shopify vs orders in OMS" catches any gaps that the webhook system doesn't. Belt-and-suspenders that costs almost nothing and saves from the rare lost-event scenario.