Connecting an ERP to Shopify: ownership, patterns, operations

Data ownership means that for every object exactly one system holds the value that counts when the two disagree. Without that decision both sides write the same field and the last write wins, not the correct one. Most so-called sync problems are unresolved responsibilities rather than technical faults.

The answer is decided per object, not per system. An ERP can own the product master and inventory and still have nothing to say about product descriptions. Shopify can own orders and still not issue the document numbers that accounting relies on. Both at once is the normal case, not the exception.

Two questions settle almost every individual case: who creates the object, and who corrects it when something is wrong. If a refund is booked in accounting, it belongs in the ERP. If it is triggered in the Shopify admin, Shopify has to own it and the ERP follows the movement.

Whoever creates an object usually owns it. Products originate in purchasing, so in the ERP. Orders originate in the checkout, so in Shopify. Customer accounts originate at both ends — which is why this one object is where the discussion starts in almost every project.

The second question is the harder one: who corrects things when they are wrong. If accounting fixes a wrong billing address in the ERP and that change never reaches Shopify, the store keeps working with the old state. Whoever corrects data must be allowed to write it, otherwise the correction has no effect.

For shared objects it helps to cut ownership at field level rather than object level. On the customer, the ERP owns the account number, payment terms and credit limit, while Shopify owns the login, newsletter consent and the addresses on the account. Each side writes only its own fields and leaves the others untouched.

Four patterns show up in practice: a native connector from the ERP vendor, an iPaaS platform, custom middleware, and a direct coupling through both APIs. The choice depends less on budget than on how far your processes deviate from the standard and who operates the integration after launch.

A connector is the fastest route as long as your processes match the standard. As soon as customer-specific prices, multiple warehouses or your own order logic enter the picture, that standard ends. The real question then is whether the connector can be extended at that point or whether you have to bypass it there.

One question decides more often than the technology: who picks up the phone on Monday morning when no orders have reached the ERP since Friday. Where there is no clear answer, the pattern with the largest custom-built share is usually the wrong one, even when it fits best on paper.

Event-driven means a transaction triggers a transfer immediately, usually through webhooks. That suits everything that has to be fast — an order into the ERP, an inventory change after a sale. The price is that you have to handle lost and duplicated events yourself.

Interval syncs run at fixed intervals and pick up everything that changed since the last run. That is more robust against outages and easier on API quotas, but it costs freshness. For the product master and prices it is almost always enough; for inventory on scarce goods it often is not.

The nightly full reconciliation is the safety net. It compares both sides completely and reports what drifted apart during the day. Without it, nobody notices that a handful of products have carried a wrong stock level for weeks. With it, the discrepancy is a morning report instead of a later complaint.

Every interface eventually sends the same message twice. A timeout, a restart, a redelivered webhook — you cannot prevent that, only absorb it. Idempotency means the second run produces the same result as the first and does not create a second order in the ERP.

Technically this rests on a business key stored on both sides: the Shopify order number as a reference on the ERP order, the ERP document number as a metafield on the order. Before every write the interface checks whether that key already exists. Only when it is missing does it create anything.

Retries need spacing. A failed call repeated immediately and endlessly burns your API quota and hides the actual cause. The common approach is a few attempts with growing intervals; after that the transaction lands in a visible error queue rather than disappearing.

The most dangerous state of an integration is not a crash but silence. A process that transfers nothing and throws no error is often noticed only when someone complains. That is why you monitor not just errors but also the absence of successful transfers.

Errors need a destination. A transaction that fails after all attempts belongs in a visible queue with payload, timestamp and error message — not in a log line nobody reads. From that queue a single transaction has to be replayable without repeating the entire run.

It helps to separate business errors from technical ones. A missing variant mapping is a data problem and needs a human. A timeout is a technical problem and usually resolves on the next attempt. Pour both into the same channel and people will soon ignore both.

The expensive mistakes are rarely exotic. They almost always come from a model being cut finer or coarser in the ERP than in Shopify, so something is lost in the mapping. Naming those spots before you build saves you from hunting for them in live operations.

Errors that move money are the nastiest. A refund executed twice goes unnoticed by everyone except accounting at month-end close. That is exactly why every money-moving transaction belongs behind a key that blocks the second execution, instead of relying on careful handling.

The sequence follows the risk. What has no effect on money and customers comes first, what creates postings when it fails comes last. That way you build confidence in data quality before the interface triggers transactions somebody has to reverse by hand.

Not every brand needs the full programme. With few orders a day and a manageable assortment, an orderly manual handover is often cheaper than an integration that wants to be operated. The maths flips as soon as duplicate maintenance produces errors instead of merely costing time.