Why Integrations Fail (and How to Build Ones That Last)

Most integrations don't fail with an error message. They fail silently. A token expires, a webhook stops firing, an overnight sync skips a batch — and because nothing crashes, nobody notices for weeks. By the time someone spots that the figures don't add up, you've got missing invoices, duplicate contacts and a reconciliation job that takes days.

That's the uncomfortable truth behind the "set it and forget it" marketing. Integrations aren't appliances. They're living connections between systems that keep changing underneath them. An integration that worked perfectly on launch day is, six months later, running against APIs, data and credentials that have all quietly moved on. This guide is an honest look at why that happens — and how to build integrations that stay alive.

Why "simple" connectors aren't as simple as they look

Before the failure modes, a reality check, because a lot of integration pain starts with a mismatch between the marketing and the actual work.

Vendors love the phrase "one-click integration". For genuinely simple, popular pairings it can be close to true. But the moment money, stock or tax is involved, "one-click" tends to mean "one click to install, then weeks of configuration to make it correct". Connecting Shopify to Xero or HubSpot is the classic example: the connector installs in minutes, but you still have to decide how orders map to invoices, how refunds and partial refunds are handled, which VAT rates apply, how gift cards and discounts post, how multi-currency is treated, and what happens to a sale that hasn't been paid yet. None of that is one-click. It's accounting logic, and getting it wrong means your books are quietly wrong.

So the first failure mode is expectation. People buy a connector expecting a finished result and get a configurable framework instead. The integration then "fails" not because it broke, but because it was never set up to match how the business actually runs.

The real failure modes

Here are the patterns we see again and again. Most integrations that go dark hit two or three of these at once.

DIY automations with no error handling

A no-code Zap or scenario thrown together in an afternoon is brilliant for low-stakes glue. The problem is that the quick version usually has no error handling at all. When step three of five fails, the first two have already run. You get a half-finished record, no rollback, and — crucially — no signal that anything went wrong. The automation reports success on the steps it completed and stays silent on the one it didn't.

For a Slack notification, fine. For "create the invoice, then mark the order paid, then update stock", a partial failure is a genuine financial mess.

API changes and deprecations

Every system you connect to is a moving target. Vendors version their APIs, deprecate old ones, change required fields, tighten validation and occasionally retire endpoints entirely. They usually announce it — in a developer changelog nobody on your team is reading.

When a provider sunsets an endpoint your integration depends on, you don't get a polite warning in your inbox. It starts returning errors, or worse, the endpoint keeps working but changes its behaviour subtly. An integration nobody is watching sails straight past the deprecation date and stops.

OAuth token expiry

This is probably the single most common cause of an integration "just stopping". Most modern APIs use OAuth, where access is granted via a token that expires and must be refreshed. Done properly, refresh is automatic and invisible. But refresh tokens themselves can expire or be revoked — when a password changes, when an admin removes an app's access, when the granting user leaves the company, or simply after a vendor-defined period of inactivity.

When that happens the connection dies, and a dead OAuth connection is silent by default. No data flows, no error lands in anyone's inbox, and the integration sits there looking installed while doing nothing.

Rate limits

APIs cap how many requests you can make in a given window. A normal day stays well under the limit, so it never comes up — until a busy sale day, a bulk import or a catch-up sync after an outage suddenly fires thousands of requests at once. The API starts rejecting calls. A well-built integration backs off and retries; a fragile one drops those records on the floor and moves on, leaving gaps you won't notice until later.

Data drift and duplicates

Integrations assume the data on both sides stays clean and matchable. In reality, data drifts. Someone edits a customer name in one system but not the other. A product SKU changes. An email address gets a typo. The matching key the integration relies on stops matching — so instead of updating the existing record, it creates a new one. Do that for a few months and you've got duplicate contacts, split customer histories and reporting you can't trust. Deduplication and a stable matching strategy aren't optional extras; they're what keeps both systems agreeing with each other over time.

No monitoring, so failures are invisible

This is the multiplier that turns every other failure mode into a disaster. Almost none of the failures above announce themselves. The token expiry, the skipped batch, the duplicate, the deprecated endpoint — they all happen quietly. If nothing is actively checking that the integration is doing what it should, the first person to find out is a customer, an auditor, or whoever is staring at month-end numbers that won't reconcile.

An integration without monitoring isn't really running. It's running until it isn't, and you've chosen not to be told which.

Staff churn and lost knowledge

The final failure mode is human. Very often the integration was built or configured by one person — the ops manager who's handy with Zapier, the developer who left last year, the founder who wired it up in the early days. When they go, the knowledge goes with them. Nobody knows which account owns the connection, what the field-mapping logic was, why that one odd filter exists, or how to fix it when it breaks. The integration becomes a black box everyone is afraid to touch, and the first serious failure becomes a crisis because there's no one left who understands it.

How to build integrations that last

The good news: every one of these failure modes is preventable. Durable integrations aren't more clever than fragile ones — they're more disciplined. Here's what "built to last" actually involves.

Practice	What it prevents
Error handling and retries	Silent partial failures, dropped records on rate limits
Monitoring and alerting	Failures that go unnoticed for weeks
Idempotency	Duplicate invoices, double charges on re-runs
Reconciliation jobs	Slow data drift between systems
Documentation	Knowledge loss when people leave
A named owner	"Not my job" becoming nobody's job
Ongoing care	Deprecations and token expiry catching you out

Build in error handling and retries

Every step that can fail should be assumed to fail eventually. That means catching errors explicitly, retrying transient failures with sensible back-off (especially for rate limits), and routing anything that can't be recovered to a dead-letter queue or a flagged "needs attention" list — not silently dropping it. The goal is simple: no failure should ever be invisible, and no failure should ever leave the systems in a half-updated state.

Monitor and alert — the non-negotiable

If you do only one thing from this list, do this. The integration should actively report that it's healthy, and shout when it isn't. That means alerts on failed runs, on authentication errors, and — importantly — on the absence of expected activity ("we normally sync 200 orders by 9am; today it's zero"). A dead-man's-switch that fires when nothing has run is what catches the silent OAuth death. Send alerts somewhere a human will actually see them, like email or Slack, not a log file nobody opens.

Make operations idempotent

Idempotency means re-running the same operation produces the same result, not a duplicate. If a sync is interrupted and re-runs, it must update the existing invoice rather than create a second one. This is what makes retries safe — without it, your error-handling and retry logic can cause as much damage as the failure it was meant to fix. Stable external IDs and "create-or-update" logic are the foundation.

Run reconciliation and dedupe

For anything touching money or stock, a periodic reconciliation job earns its keep. It compares both systems, flags records that don't match, and surfaces drift before it compounds. Pair it with a deliberate deduplication strategy — a stable matching key, fuzzy matching where appropriate, and a clear rule for what to do when a match is ambiguous.

Document it, and name an owner

Write down what connects to what, which account owns each connection, the field mappings, the business rules, and the recovery steps for common failures. Then make it someone's explicit responsibility. "The integrations" shouldn't belong to whoever happens to remember them. An owner means deprecation notices get read, expiring credentials get rotated, and a failure has a clear first responder.

Treat it as something to maintain, not finish

This is the mindset shift. An integration is never "done", because the systems it connects are never done. The most reliable setups we see are treated like any other piece of operational infrastructure: monitored, patched, and reviewed on a cadence. Someone watches the dashboards, applies API changes before they break things, rotates credentials, and makes small improvements as the business grows. That ongoing care is far cheaper than the firefight that follows three months of silent failure — though the right level of cover depends on how much rides on the connection.

The honest takeaway

Integrations don't usually fail because they were built badly. They fail because they were built once and then left alone in a world that kept changing — APIs deprecated, tokens expired, data drifted, and the one person who understood it moved on, all while nothing was watching. The fix isn't more sophistication. It's error handling, monitoring, idempotency, documentation, clear ownership and ongoing care. Boring, unglamorous discipline is what keeps an integration alive for years instead of months.

How APIwise can help

We're a UK-based, vendor-neutral integration team, and keeping integrations alive is the part most people skip. Every build we deliver ships with proper error handling, monitoring and alerting, idempotent operations and handover documentation — so failures surface immediately and your data stays trustworthy.

If you already have integrations that feel fragile, keep breaking, or that nobody quite understands any more, our fixed-price Integration Health Check maps every connection, finds the silent failure points, and gives you a prioritised plan to make them durable. For connections that matter, our Care & Connect Retainer means someone is watching the dashboards and applying API changes before they bite. (All our prices are fixed and quoted up front; the figures you'll see across our site are indicative UK ranges, not a quote.)

Book your Integration Health Check, or explore our API integration, AI automation and data integration services. If you're wrestling with a specific stack, we also work as a Xero integration specialist and a HubSpot–Salesforce integration partner.