Why integrations fail and what to do about it

Most integration failures are really process and ownership failures. Not a broken connector, a vendor limitation, or a developer error.

The root cause is almost always the same: teams move too fast, define too little, and assume too much before a single line of code is written.

Having worked on integrations for fast-growing ecommerce brands across multiple regions, the pattern is consistent. The technical complexity is real, but it is rarely the main blocker. What slows things down, and what eventually breaks them, is everything that happens before and around the code.

People tend to think of integration as connecting two systems. Map the fields, turn on the connector, and done.

In reality, a stable integration requires validation, error handling, endpoint management, authentication and security. And that is before you consider that no integration operates in isolation. "Orders from Shopify to the warehouse" is one step in a much longer chain of events.

If you only look at that one step, you miss most of the ways it can fail.

Early on, you can absorb failure manually. A small number of orders go wrong, someone fixes them, and life goes on.

But volume changes everything. Manual fixes turn into a large team, with a high error rate and high cost. What worked for a hundred orders a day breaks at a thousand. By the time that happens, teams are firefighting instead of building.

The approach has to move from "we will fix it manually" to "the system detects and manages every transaction, and we know quickly when something goes wrong."

When integrations go wrong, the easiest diagnosis is the tool. This system is not working, the API is unreliable, and this platform cannot handle that logic. But in most cases, it is not the tool. It’s how the tool was implemented, and whether its limitations were understood before go-live.

Here's an example: when integrating sales orders from Shopify to a warehouse, one of the most common failure points is the mismatch between the order types Shopify generates and the order types the warehouse accepts. This is a known data structure difference, and it consistently surfaces in production because no one asked the question upfront.

Alongside that, teams often lack a proper rollback or backup process for when things go wrong. Customer service and operations need to know what to do when an error occurs, not figure it out in the moment. That contingency planning is not glamorous, but it is the difference between a recoverable incident and a customer-facing crisis.

Unclear ownership

Integration responsibility cannot sit with a single team. Integrations touch customer service, IT, ecommerce and sales. When ownership is unclear, error handling falls into the gap, and errors will happen at any meaningful scale. The question is whether there is a well-defined team ready to manage them or whether every incident becomes a conversation about whose problem it is.

Underestimating the impact of change

This is probably the most common trigger for unexpected failures in otherwise stable integrations. Teams add a new shipping method, a new product type or a new returns flow and assume it will not affect anything else. It almost always does. Any change to a production environment needs to be validated across the systems it touches before it goes live. This is where integrations that "worked fine" suddenly stop working.

No observability

Without monitoring and reports, errors do not get detected in advance. By the time the problem surfaces, the damage is already done. Good observability means knowing when an integration is not performing as expected, whether that is error rates, data volumes or the speed at which data is moving between systems. It’s not an optional extra.

Testing only the happy path

"The most dangerous phrase in integrations is: it worked once."

Moving something to production after testing one scenario is not enough. Integrations need to be tested for what happens when things go wrong, not just when they go right. What is the rollback process? What happens to in-flight orders during a failure? How does the system recover? These questions need answers before go-live.

The integrations that run without incident share the same pattern: good planning upfront, clear validation with the right people, and enough time to run proper tests. Teams that want everything ready immediately are usually the first to run into problems. Taking time to plan properly is not a delay; it's what prevents a much costlier one later.

On tools: not all are equal, and flexibility matters. If your data or strategy requires customisation, you need a tool that can accommodate that. When evaluating options, one of the most important questions is how easy it is to change specific requirements after go-live. If making changes is slow, difficult or frequently hits a wall, that is where problems accumulate.

Requirements also need to be locked before implementation begins. Changes are possible, but each one requires a new scope, new testing, and a new deployment. Treating a requirement change as a minor adjustment is how you end up with a broken integration that nobody can fully explain.

Most integration failures are preventable. Not all of them, but most.

The patterns are consistent enough that we see them before they happen. Unclear ownership, requirements that were never locked, changes deployed without validation, and monitoring that did not exist until the first incident.

None of these are technical problems. They are process and planning problems, and they respond to process and planning solutions.

If you are building out an integration or inheriting one that is starting to creak, the question to ask is not "which system is the problem?" It's do we have clear ownership, a validated spec and the monitoring to know when something breaks?

Want to discuss this in more detail? Get in touch