Black Friday 2024. A seller ran three stores out of a single warehouse, and the TikTok Shop orders arrived six hours late into the WMS. The hero SKU sold out in forty minutes; the platform still showed inventory on hand. Three hundred-plus oversells, and the customer service line melted down. The warehouse team felt wronged — the stock was there; the orders just showed up late. The root cause wasn't in the warehouse at all. It was the order ingestion design, chosen wrong from day one.
A decade ago multichannel meant "we have a Shopify store." Now it's Shopify, Amazon, TikTok Shop, and Walmart all at once, with orders pouring into one WMS from four directions. There are only two ways to pipe them in: polling — asking each platform every few minutes "any new orders?" — or webhooks, where the platform pushes new orders to you the moment they happen. Which one you pick decides whether your order latency is measured in minutes or seconds, and whether you sleep or firefight on peak day.
The difference isn't just speed
Most people treat this as a fast-versus-slow choice. That's naive. The two approaches differ on four axes:
Latency. Polling latency equals your polling interval — poll every five minutes, average latency is two and a half. Webhooks push in seconds. Nobody notices two and a half minutes on a normal Tuesday. When a hero SKU sells through in forty minutes, that delay multiplied across four platforms is overselling.
Cost. Polling spends your API call budget. Amazon's SP-API enforces strict rate limits; exceed your quota and you get throttled. The bigger your volume, the more often you poll, the closer you sail to the rate-limit wall. Webhooks don't consume your quota — the platform pushes, you receive.
Reliability. Polling rarely loses an order — if you asked, you got the answer. Webhooks die in two ways: the platform pushed and you never received it (network blip), or you received it and didn't process it cleanly (service restart). So webhooks demand retries and idempotency: the same order pushed three times must exist exactly once in the WMS. I've seen more than one operation learn this during peak, when duplicate order creation meant double shipments.
Platform support. Not every platform offers webhooks. Shopify's are mature, TikTok Shop provides order push notifications, Amazon leans on its SP-API Notifications mechanism — each with its own semantics. Check each platform's current developer docs; don't apply last year's integration knowledge to this year's APIs.
The Amazon case deserves a special warning. SP-API rate limits are per-operation and genuinely enforced — I know a 3PL that polled order status aggressively during a Prime Day surge, got throttled for the better part of an hour, and spent that hour blind while orders piled up. Their fix was a token-bucket limiter on their own side plus exponential backoff, which is what they should have built on day one. If you poll Amazon, budget your quota like money: assign each job a call allowance, log consumption, and alert at 80%. Throttling during peak is a self-inflicted wound.
My recommendation: pick by order volume
Forget the technology debate. Look at your own volume and take the matching tier:
Under 500 orders a day: polling is fine. Hit all four platforms every five minutes. Latency is acceptable, development takes one engineer a few days. Spend the saved time on reconciliation instead.
500 to 5,000 a day: webhooks primary, polling as backup. Webhooks handle real time; an hourly full pull catches whatever the webhooks dropped. Best value-for-effort combination I know, and the most common setup among mid-size sellers I've worked with.
Over 5,000 a day: webhooks into a message queue, plus reconciliation. Pushes land in a queue to absorb spikes, consumers deduplicate idempotently, and a nightly full reconciliation compares platform orders against WMS orders. Load-test a push storm before peak — platforms push later and duplicate more during their own big events, and going in untested is flying blind.
Whichever tier you're in, three rules are non-negotiable. One: make the platform order ID a global unique key and silently drop duplicates. Two: always verify webhook signatures — I've seen an operation skip verification to save time and get its database flooded with forged orders. Three: keep an hourly full reconciliation job running. This is the life insurance of every multichannel warehouse — webhooks drop, polling misses, reconciliation doesn't lie.
That reconciliation job deserves a design note of its own, because most teams build it wrong. Don't compare "orders created in the last hour" — compare the full set of open orders on each platform against open orders in the WMS, by platform order ID. The job should produce exactly three lists: platform orders missing from the WMS (ingestion gap — pull them in), WMS orders missing from the platform (cancelled or refunded upstream — flag for review), and status mismatches (shipped on one side, pending on the other — investigate). Run it hourly, page someone on the first list, and log the other two. An hour of engineering here saves a Black Friday.
That seller from the opening story? They moved to webhooks plus hourly reconciliation. The next Black Friday: 20,000 orders across four platforms, zero oversells. No ingestion pattern is inherently superior — there's only the one that matches your volume. Count your orders first, then pick the pipe. Never the other way around.
