Integrations that look connected but are not
The most expensive integration problems do not announce themselves. There is no error message and no red banner. The connection reports healthy, orders flow, and then a customer buys something you do not have, or an order sits for two days in a status nobody monitors. Here are the failure modes we see most, and the tests that find them before your customers do.
Why "connected" is the wrong question
Most integration status indicators tell you one thing: whether credentials work and an API responded. That is necessary and nowhere near sufficient. An integration can authenticate perfectly and still be mapping the wrong SKU, syncing in one direction only, or silently skipping the order types nobody tested.
The useful question is not "is it connected" but "which specific events flow, in which direction, and what happens to the ones that fail." Those are three different questions, and a green checkmark answers none of them.
The rule of thumb: an integration is only as good as its least-tested path. Orders flow because everyone tests orders. Cancellations, partial shipments, bundles, exchanges, and address corrections are where the money leaks, because nobody writes a test order for a refund.
The six failure modes
1. Inventory location not set
The classic. On Shopify specifically, the SKU has to exist in your store and your fulfillment provider has to be set as an inventory location on your side. Miss the second half and your storefront happily sells from a location that reports nothing back. This is a configuration on your end, which is why it survives a provider's testing.
2. Sync direction assumed rather than confirmed
Which system is authoritative for inventory: your cart or the warehouse? There is a correct answer for your business, and the failure is not choosing wrong, it is never deciding. When both systems believe they are authoritative, they overwrite each other and the count oscillates. When neither does, drift accumulates silently.
3. SKU mismatch on bundles and part-pointers
Your channel SKU frequently is not the warehouse SKU. Bundles are the hard case: a storefront sells one item, the warehouse picks three, and inventory has to decrement three records while the order shows one line. If the mapping is wrong, availability is wrong for every component, which means one bad bundle mapping can misreport several products at once.
4. Untested order types
Test orders are almost always simple: one item, one address, standard shipping. Production is not. Pre-orders, backorders, split shipments, subscription renewals, gift orders with a separate ship-to, exchanges, and orders with a discount that changes the recorded value all behave differently. Each is a path, and each unmapped path becomes a stuck order.
5. Failures that fail quietly
The worst design in integration is the silent skip. An order that cannot be processed should stop somewhere visible with a name attached. Too often it is logged and dropped, which means the first person to notice is the customer, days later.
This is why we treat "fail loud" as a design rule rather than a preference. When something cannot be processed, it should surface for a human rather than resolve itself into a plausible default. An order sitting in an exceptions queue that somebody owns is a minor operational task. The same order silently absent is a support crisis with no record of what happened.
6. Nobody watching the queue
Even good exception handling fails if the queue has no owner. An exceptions queue is only a control if a named person drains it on a known cadence. Otherwise it is a very well-organized list of problems you are not solving.
Our Exception Reports exist to surface problems before you feel them, and models watch every carrier scan to flag shipments trending toward trouble so our team can reroute, reship, or start a claim review before your customer writes the one-star review. The report is the easy part. Somebody owning it is the part that matters.
The tests worth running before go-live
We do this during a specific gate of a transition rather than in launch week, and it is the same list we would hand you to run against any provider.
| Test | Catches |
|---|---|
| One order per channel | Credentials, mapping, and label generation per sales channel, not just the biggest one |
| A bundle order | Component mapping and multi-record inventory decrement |
| A multi-item, multi-carton order | Split shipment handling and per-package surcharge exposure |
| A cancellation after fulfillment starts | The race condition nobody tests and everybody hits |
| An address that fails validation | Whether a correctable error stops visibly or disappears |
| An out-of-stock order | Backorder behaviour and whether the storefront updates |
| A return through the full loop | Restock, disposition, and whether availability comes back |
| Inventory adjustment both directions | Which system wins, confirmed rather than assumed |
Eight tests. A couple of hours of somebody's afternoon. They catch the overwhelming majority of what otherwise surfaces in your first busy week.
What to insist on from a provider
- A written map of what syncs, in which direction. If it only exists in somebody's head, it does not exist.
- Named ownership of the exceptions queue. Ask who drains it and how often.
- Visibility you do not have to request. Order status and inventory position should be live in a portal you can export from.
- Tested paths, not configured ones. Configuration is a claim. A test order is evidence.
- Someone who will tell you what does not connect natively. Our integrations page lists what does, and a provider unwilling to name the gaps is describing a brochure.
Why we build these rather than buy them
Integration edge cases are specific to how a brand sells, which makes them exactly the category of problem that off-the-shelf platforms handle generically and imperfectly. Custom routing rules, cart integrations, and kitting logic get built, tested, and shipped by our engineers, which is why an unusual order type is a change we can make rather than a limitation you work around. We wrote more about that trade in why your 3PL should write its own software.
The bottom line
Integrations do not usually break. They quietly do slightly the wrong thing, on the paths nobody tested, until a customer finds it. The fix is unglamorous: enumerate the paths, test the awkward ones, make failures visible, and give the exceptions queue an owner.
Run the eight tests. They are cheap, and they are the difference between a launch week and an incident.
Related reading
Inventory accuracy is a revenue problem
Channel sync is one of six places counts drift. Here are the other five.
Read →Why your 3PL should write its own software
What changes when the company packing your orders also owns the code.
Read →Have us test your integration paths
Book a call and bring your channel list and your awkward order types: bundles, subscriptions, pre-orders, whatever breaks. We will tell you which paths need building and which connect natively. Thirty minutes, and no pretending everything is native.
Book a discovery call