Integrating a Web ERP with E-commerce Platforms
For many businesses the e-commerce store is where orders are born and the ERP is where they must end up. The integration looks simple on a whiteboard — orders in, inventory out — and then reality arrives: rate limits, webhook storms, partial failures, SKU mismatches. This article covers the patterns we use to keep ERP and marketplace in sync without a human re-keying anything.
The three sync surfaces
Treat platform integration as three separate pipelines, each with its own direction, cadence and failure handling:
- Order sync (inbound) — marketplace orders become ERP sales orders.
- Inventory sync (outbound) — ERP stock levels become platform listings' available quantities.
- Product sync (outbound, slower) — items, prices and descriptions flow from ERP to the platform, usually master-data driven.
Order sync: pull beats push for correctness
Platforms offer webhooks for new orders, and webhooks are fine as a notification — but never as the only source. Webhooks get lost, arrive out of order, and duplicate. The reliable pattern:
- Webhook (or a periodic poll every few minutes) triggers an incremental order fetch from the platform API with a persisted
last_synced_atwatermark. - Each fetched order is mapped to an ERP sales order with the platform order ID stored as a unique external key.
- The unique key makes ingestion idempotent: re-fetching the same order updates the existing ERP document instead of creating a duplicate.
- Order state changes (paid, shipped, refunded) follow the same watermark pipeline in reverse — ERP shipment confirmations push tracking numbers back to the platform.
Polling every two to five minutes is plenty for everyone except flash-sale scenarios, and it converts "did we miss a webhook?" from an incident into a non-question.
Inventory sync: debounce and prioritize
Available stock changes constantly — every receipt, issue and adjustment can trigger a push. Pushing every change floods the platform API and hits rate limits. Instead:
- Debounce — accumulate changes per SKU for a short window (30–60 seconds) and push only the latest value.
- Prioritize — SKUs at or below safety stock get pushed immediately; slow movers join the debounced batch.
- Reserve, don't oversell — push
available = on_hand - reserved - safety_stock. Race conditions between two channels both selling the last unit are handled by the platform at checkout; your job is to make that race rare.
Product sync: the master-data contract
Product sync fails silently more often than anything else: SKUs that exist on one side only, units that don't match, categories mapped by habit. Fix this with an explicit contract:
- One SKU field is canonical in both systems, immutable, no "almost the same" variants.
- A mapping table covers the fields that genuinely differ (platform category IDs, listing titles, tax classes), and it is reviewed, not improvised.
- Sync runs as a batch report: before pushing, generate a diff of what would change; a human glances at it until the process has earned trust.
Idempotency and retries are the baseline
Every outbound call carries an idempotency key; every inbound message is deduplicated by external ID. Retries use exponential backoff with jitter, and failed operations land on a dead-letter queue with a retry UI — an operator can inspect, fix the mapping and re-run a failed sync instead of asking engineering. The same discipline appears inside the ERP's own posting pipeline; see Integrating General Ledger with Business Documents for the idempotency patterns applied to finance.
Conclusion
Platform integration is an exercise in distrust: distrust webhooks (watermark and poll), distrust single deliveries (idempotency keys), distrust volume (debounce and prioritize). Build those three habits in from day one and the ERP stays the single source of truth even when the marketplace has a bad day. When the same reliability mindset is needed on screen, the UI patterns in Enterprise Web UI Patterns apply just as well to integration monitoring dashboards.