Two systems, one truth — pick which is which
The first decision in any Shopify–ERP integration isn't technical. It's deciding, per data type, which system is the source of truth. Shopify is your commerce layer: it owns the storefront, the cart, the checkout, the customer-facing experience. The ERP is usually your operational source of truth: it owns inventory, pricing logic, accounting, and the master record of what your business actually has and owes.
Get this wrong and you build a loop where two systems each think they're in charge of the same number, overwrite each other, and drift apart by the day. Get it right and the rule is simple: each field has exactly one owner, and the integration's job is to move changes from the owner to the follower, reliably, in one direction or in a clearly defined two-way sync. Everything else in this article is downstream of that decision.
What breaks in naive integrations
Most failing integrations weren't designed to fail — they were designed only for the happy path. The failures are predictable:
One-off scripts with no recovery. A script that fetches orders and pushes them to the ERP works beautifully in a demo. In production it hits a network blip, throws, and stops — and nobody notices until orders are missing days later. A script is not an integration; it's the part of an integration that runs when nothing goes wrong.
Rate limits. Shopify's APIs are rate-limited, and the GraphQL Admin API uses a cost-based budget. A naive sync that fires requests in a tight loop gets throttled, drops calls, and loses data silently. Respecting limits — backoff, batching, working within the cost budget — is not optional at volume.
Schema drift. The ERP adds a field, renames a status, changes a code. The integration, hard-coded to yesterday's shape, keeps running and quietly writes garbage. Without validation at the boundary, drift is invisible until it's a reconciliation nightmare.
No retries, no idempotency. A webhook fires, the handler half-completes, and there's no safe way to run it again — so a retry double-creates an order or double-decrements stock. Or a webhook is missed entirely because its HMAC check failed silently and the event was dropped. These are the same failure modes behind the order-sync leaks in how to find revenue leaks in a Shopify store.
The common thread: naive integrations treat success as the only outcome. Production is mostly edge cases.
What's worth syncing
Not everything needs to flow between the two systems. The high-value, recurring syncs:
- Inventory. Usually ERP or WMS to Shopify. Late or wrong inventory causes overselling, refunds, and oversells that read as a fulfilment problem but are really a sync problem.
- Orders. Shopify to ERP, on a verified webhook, so every paid order lands in the operational system to be picked, packed, and invoiced.
- Customers. Often two-way, with one owner per field. Be deliberate here — customer data is where two-way sync goes wrong most often.
- Fulfilment and tracking. WMS or 3PL back to Shopify, so the customer sees accurate status and your team isn't fielding "where's my order" tickets. This is core Shopify automation territory, and a recurring win in what to automate in a growing store.
- Accounting. Orders, refunds, and payouts into the finance system, so the books reconcile without manual export-import.
Each of these wants its own owner, its own direction, and its own definition of "done." Lumping them into one giant two-way sync is how integrations become un-debuggable.
The infrastructure that makes it stable
The difference between a script and a real integration is everything that handles failure. None of it is glamorous; all of it is load-bearing.
- A queue. Don't process events inline in the webhook handler. Accept the event, acknowledge it fast, and put the work on a queue. The queue absorbs spikes, smooths around rate limits, and lets you retry without losing data.
- Idempotency. Every operation must be safe to run twice. Key on the order ID or a unique event ID so a retried webhook updates rather than duplicates. This single property prevents most of the worst production incidents.
- Retries with backoff. Transient failures — a timeout, a throttle, a brief ERP outage — should retry automatically with increasing delay, then land in a dead-letter queue for a human if they keep failing. Failures should be visible, not silent.
- Logging and monitoring. Every sync logged, every failure surfaced. You want to know an order didn't reach the ERP within minutes, from a dashboard or an alert — not next week from an angry customer. The data layer behind this is covered in Shopify GraphQL, webhooks and dashboards explained.
- Validation at the boundary. Check incoming data against the shape you expect before you write it. When schema drift happens — and it will — you want it to raise an alarm, not corrupt your records.
This infrastructure is most of why a real Shopify ERP integration costs more than a quick script. It's also most of why it survives. Whether to build it as a focused custom app or a broader integration is exactly the kind of trade-off in private Shopify apps vs public apps.
What to avoid
- Generic connector apps for non-generic operations. An off-the-shelf Shopify-to-ERP connector is fine when your operation matches its assumptions. The moment you have a pricing tier, a fulfilment quirk, or a custom status it can't model, you're back to working around the tool — the same trap described in when to replace Shopify plugins with a custom app.
- Two-way sync where one-way would do. Bidirectional sync is harder by an order of magnitude. Only build it where the business genuinely needs both systems to write the same field.
- Real-time everything. Not every sync needs to be instant. Inventory might be near-real-time; accounting can be batched hourly. Forcing everything to real-time multiplies cost and fragility for no operational gain.
- Building it as a side project. An integration that touches inventory, orders, and money is not a weekend script. Treat it as the production system it is, or it will fail at the worst possible time.
Where to start
The right first step is a map: which systems own which data, where they currently disagree, and which syncs would remove the most manual work and risk. A paid Shopify audit produces exactly that — a ranked, honest picture of what to integrate, in what order, before any code is written. If you'd like a lighter first look, the free Shopify audit is a quick scan to surface the obvious gaps.