Almost every distributor we assess has an integration between Shopify and their ERP. It usually works. What they want to talk about is not whether it works, but the fact that nobody is quite sure what happens if it stops.
That is the real shape of the problem. Custom integrations rarely fail at launch, because launch is when everyone is paying attention. They fail eighteen months later, on a Tuesday, in a way nobody notices until a customer asks where their order is.
The build is the easy part
A developer who understands both APIs can connect Shopify to an ERP. Orders out, inventory back, tracking posted when a shipment goes out. It is well-understood work, and the person who does it usually does it well.
Then the project ends. The developer moves to the next thing, or the agency contract closes, and the integration enters a phase nobody scoped: the years it spends running.
This is the part that gets costed at zero. The quote covers the build. The maintenance is assumed to be nothing, because the thing works when it is handed over, and working software does not obviously need anyone.
Four ways it degrades
The failure modes are boringly consistent. We see the same four.
The API moves underneath it. Shopify versions its API quarterly and retires versions on a published schedule. Your ERP vendor ships updates on their own calendar. Neither one is going to ask whether your script is ready. A field gets deprecated, a response shape changes, and code written against last year’s contract starts behaving differently. Sometimes it throws an error. More often it silently reads a null where it used to read a date.
The business changes and the code does not. You add a second warehouse. You take on a dropship vendor whose lines should not decrement your own stock. You start selling a bundle that is one SKU in Shopify and four in the ERP. The integration was written for how you operated when it was written, and nothing about adding a vendor prompts anyone to revisit it.
The credential expires. OAuth tokens get revoked, refreshed, or rotated. An employee whose account authorized the connection leaves and their access is removed. The integration stops authenticating, and whether anyone finds out depends entirely on whether something was watching.
It fails open. This is the worst one, and the most common. A sync fails, the error goes to a log nobody reads, and the system carries on. No alert fires because nobody built alerting, since alerting was not in the original scope. The integration is not down. It is just quietly not doing its job, and the first person to find out is a customer.
Why nobody notices
Here is the thing about a broken integration: it looks exactly like a working one from the outside.
Shopify is up. The ERP is up. Orders are coming in and most of them are fine. What is actually happening is that a subset of records stopped moving, and the symptoms show up somewhere else entirely, as a support ticket about a late order, or an inventory count that drifted, or a customer charged for something you cannot ship.
By the time somebody traces it back to the integration, it has usually been broken for weeks. We have seen gaps measured in months.
The reason is structural, not a failure of diligence. Nobody is assigned to it. Operations assumes IT owns it. IT assumes the agency that built it owns it. The agency assumes the engagement ended when they handed it over. Everyone is being reasonable, and the integration has no owner.
The question that actually matters
When teams compare integration options, the comparison is usually about capability. Can it sync purchase orders. Does it handle multi-location inventory. Can it map our custom fields.
Those are real questions, but they are answerable by any of the options. The question that separates them is the one that gets asked last, if at all:
Who is responsible when this breaks, and how will they know?
Run the four approaches through it:
A native connector is maintained by its vendor, for the connector. Nobody maintains the gap between what it does and what your process needs, and that gap comes back to your team as manual work.
Middleware maintains the platform. The flows you build on it are yours. If the person who built them leaves, you are maintaining flows nobody on the team wrote.
A custom script has whoever is available when it breaks, which in practice means whoever can be convinced to look at unfamiliar code under time pressure.
An embedded engineer is the answer to the question by construction. They built it, they run it, they are watching it, and when it breaks it is their problem rather than a discovery you make through a customer complaint.
What monitoring actually means here
“We monitor it” is easy to say and usually means an uptime check. Uptime is not the failure mode. The integration was up the whole time it was silently dropping records.
Monitoring an integration means watching for the absence of expected work. If orders normally sync every few minutes and none have synced in two hours, that is a signal, even though nothing errored. If a sync that normally touches two hundred records touches three, that is a signal. If a credential is thirty days from expiry, that is a signal you want before it expires rather than after.
None of that is exotic. It is just work that has to be someone’s job, and it is almost never in the scope of a build-and-hand-off project, because at handoff there is no baseline yet to compare against.
The honest version of the trade-off
None of this means custom integrations are a mistake. Sometimes a custom build is exactly right, and a native connector that genuinely fits your process is better than anything bespoke. We will say so during an Assessment when it is true.
What it means is that the build cost is not the cost. The cost is the build plus however many years of ownership follow it, and the second number is the one nobody puts in the proposal.
If you have an integration today and cannot answer who gets paged when it stops, that is worth knowing before a customer tells you. It is also one of the first things an Assessment looks at, because an integration that fails open is a problem you already have, whether or not you can see it yet.
How Shopify and your ERP connect, and the four ways to do it →