Shopify ERP integration: architecture patterns and common failure modes
ERP integrations fail more often than they should — usually for the same reasons. Here's how to design one that stays reliable at scale.
ERP integrations are where commerce projects quietly succeed or fail. When they work, nobody notices. When they break, you get oversells, wrong prices, stuck orders, and a finance team that no longer trusts the data. The failures are rarely exotic — they're the same handful of design mistakes, repeated.
Decide the source of truth — explicitly
The single most important decision: for each data domain, which system is authoritative? Inventory, pricing, customer records, and orders each need one owner. Ambiguity here is the root cause of most integration chaos.
- Inventory: usually the ERP or WMS — Shopify reflects it, never overrides it
- Pricing: ERP for B2B/contract pricing; Shopify for DTC promotions
- Orders: Shopify is the source; the ERP receives them for fulfilment and finance
- Customers: depends on whether B2B account structures live in the ERP
Real-time vs batch
Not everything needs to be real-time, and pretending it does adds cost and fragility. Match the sync cadence to the business need: order push to the ERP should be near-real-time; a full product catalogue reconciliation can run nightly. Inventory usually sits in between — frequent deltas plus a periodic full sync to correct drift.
Common failure modes
No idempotency
Webhooks get delivered more than once. Without idempotency keys, a retried order webhook creates duplicate ERP orders. Every write operation must be safe to replay.
Synchronous coupling
If a Shopify event calls the ERP directly and the ERP is down, you lose the event. Put a queue between them. The integration should absorb downtime on either side and catch up, not drop data.
No reconciliation job
Deltas drift. Without a scheduled reconciliation that compares both systems and flags mismatches, small discrepancies compound silently until someone notices inventory is wrong by 200 units.
Silent failures
An integration that fails quietly is worse than one that fails loudly. Every sync needs logging, alerting on error-rate thresholds, and a dead-letter queue for messages that can't be processed — so a human finds out before a customer does.
The pattern that holds up: An event-driven middleware layer with a durable queue, idempotent writes, explicit source-of-truth rules per domain, a nightly reconciliation job, and observability on every sync. It costs more upfront than a point-to-point script — and an order of magnitude less than the failures the script will eventually cause.
Want this applied to your store?
We help brands apply exactly this kind of thinking to their actual business — working directly with senior specialists, not account managers.
Commerce engineering, in your inbox.
Occasional, technical, and genuinely useful — engineering perspectives on building faster, better commerce. No fluff.