Why Your E-commerce Integration Keeps Breaking (And How to Fix It)

You connect your Shopify store to Bol.com. Orders flow in for a week. Then one morning you find duplicate orders, missing stock updates, and a support queue that doubled overnight. You fix it. Three weeks later it happens again.

This is not bad luck. It is a predictable consequence of building integrations without accounting for the four failure modes that every multi-channel e-commerce setup eventually hits.

1. No idempotency: retries create duplicates

When a webhook or API call fails mid-flight, the sender retries. If your handler does not check whether it has already processed that event, you get two orders for one purchase, two stock decrements for one sale, two confirmation emails in the customer's inbox.

The fix is an idempotency key: a unique identifier attached to every incoming event. Before processing, check whether that key exists in your database. If it does, acknowledge the request and stop. If it does not, process and store the key atomically. Platforms like Shopify include an X-Shopify-Webhook-Id header for exactly this purpose. Use it.

2. Webhooks are not guaranteed: silent failures accumulate

Every major marketplace treats webhooks as best-effort delivery. Bol.com, Amazon, and eBay all document that webhooks may be delayed, deduplicated, or dropped entirely under load. If your integration only reacts to webhooks, you are missing events you never know about.

The solution is a reconciliation job: a scheduled process (every 15 to 60 minutes) that polls the marketplace API for orders created or updated since the last successful sync. The reconciliation job is your safety net. Webhooks are the fast path. Neither alone is sufficient.

3. Stock sync has a timing gap

You sell the last unit on Shopify at 14:00. Your stock sync job runs at 14:05. In those five minutes, the same unit is available on Bol.com. A second customer orders it. Now you have an oversell.

There are two mitigations. First, reduce sync frequency to as close to real-time as the marketplace API allows; most support near-instant stock updates via their own API endpoints, not just webhooks. Second, introduce a safety buffer: report a stock level slightly below actual (for example, actual minus one for low-stock SKUs) to absorb timing gaps. Neither is a perfect solution; the goal is to make oversells rare rather than routine.

4. API versioning is ignored until it breaks

Marketplace APIs version their endpoints. Shopify deprecates API versions on a rolling 18-month schedule. Bol.com has made breaking changes to their Retailer API with limited notice. Most integration codebases pin to whichever version worked at build time and never update it, until the endpoint is sunset and everything stops working on a Tuesday.

The fix is process, not code: track deprecation notices in a shared calendar, run integration tests against a staging environment monthly, and treat API version upgrades as planned maintenance rather than emergency work.

The pattern that makes integrations reliable

Reliable multi-channel integrations follow the same pattern regardless of which platforms are involved:

• Ingest: accept webhooks, acknowledge immediately, push to an internal queue
• Deduplicate: check the idempotency key before processing
• Process: handle the event in a background worker, with retries on transient failures
• Reconcile: a scheduled job polls the API and fills any gaps
• Alert: monitor queue depth and reconciliation drift; page on anomalies

This is not complex architecture. It is a queue, a deduplication table, and a cron job. But without all three, every integration eventually breaks, usually at the worst possible time.

If your current setup is missing any of these layers, that is where the next outage will come from.