Why Enterprise API Integrations Get More Fragile Every Year

Enterprise integrations rarely fail the way software is usually imagined to fail. They do not crash on launch. They run correctly for one, two, sometimes five years, and then one Tuesday a nightly synchronisation starts dropping records, or a checkout flow begins returning intermittent errors, and nobody can name the change that caused it. The postmortem that follows usually concludes that the integration 'broke'. The more accurate conclusion is that the integration was never as stable as it appeared. It was accumulating fragility the whole time.

The reason is structural. An integration is not code you own. It is an agreement between two systems that evolve independently, under two sets of priorities, on two release schedules. The code on your side can be versioned, tested, and reviewed. The agreement itself cannot. Everything that keeps the agreement intact lives outside your repository, in assumptions that were made once and never re-verified.

The documented contract is not the real contract

Every API has a specification: endpoints, parameters, response shapes, error codes. Every working integration also depends on things the specification does not say. That the paginator returns the newest items first. That a null field is omitted rather than returned. That timestamps arrive in UTC while the UI layer assumes local time. That a webhook fires at least once, occasionally twice. That a 200 response always carries a usable payload. None of these appear in the documentation, because from the provider's side none of them are features. They are incidentals of one particular implementation.

These undocumented behaviours become load-bearing the moment your code relies on them, which happens automatically during development. Nobody writes code against a specification. They write code against observed responses, and they keep the observations that make the code shorter. Two years later, the provider refactors an internal service, an incidental changes, and the integration fails without either party violating any documented promise. The provider will say, correctly, that nothing in the contract changed. The system was depending on the part of the contract that was never written down.

Schema drift hides behind additive change

Providers add fields far more often than they remove them, and additive change is widely treated as safe. It frequently is not. A new enum value appears in a status field and a client-side switch statement, which had handled every observed value, now falls through to a default branch that silently marks live orders as unknown. A string field that always held a number starts holding a number formatted as text. A nested object that was always present is now conditionally omitted. Each of these passed the provider's own backward compatibility review, because on their side, nothing stopped working.

The asymmetry is the point. The provider can ship a compatible change in hours. Every consumer of that change must be found, assessed, and updated across an estate the provider cannot see. In practice, most consumers learn about additive changes from their own error dashboards, days or weeks later, if they learn at all.

Versioning in name, deprecation in practice

Mature providers version their APIs and publish deprecation policies. In enterprise reality, the version number is often the only part of that machinery working as advertised. A v2 endpoint accumulates behavioural changes that never warranted a v3: new optional parameters, revised default page sizes, tightened validation that now rejects payloads the old client still sends. Deprecation notices go out by changelog and email, filtered into the inbox of whoever registered the account, who may have left the company.

Meanwhile the consumers of an integration are usually not the team that built it. The original developers moved on. The integration runs in production with the organisation's least-attended form of maintenance: none, as long as nothing visibly fails. When the provider finally enforces a breaking change, after years of grace, the organisation discovers that the person who understood the integration no longer works there, the credentials are owned by a departed employee's account, and the internal documentation describes the first version of the design.

The retry that doubles the order

Networks are unreliable, so well-built clients retry. The interaction between retries and non-idempotent operations is one of the oldest failure modes in distributed systems and still among the most common in enterprise integrations. A payment submission times out after the server received it. The client retries. The order ships twice, or the invoice books twice, and the discrepancy surfaces in reconciliation, days later, far from the system that caused it.

Idempotency keys solve this, and a growing share of APIs support them. Support is not adoption. The key must be generated, stored, and reused correctly by every client, across every retry path, including the paths added later by developers who did not know the first retry existed. An integration with idempotency in its write path and a naive retry in its webhook receiver still double-processes. The protection has to cover the whole loop, and the loop keeps gaining new segments.

Monitoring confirms the happy path

Most integration monitoring checks one thing: did the call return success. That check passes in all the situations where integrations actually decay. A 200 response with an empty result set passes. A webhook that stopped arriving passes, because nothing arrived to fail. A synchronisation that processed every record but mapped a field to the wrong column passes, and will keep passing until someone downstream asks why the numbers disagree.

The checks that catch real degradation measure content, not transport. Record counts on both sides of a synchronisation, compared daily. A canary record written into the provider and read back, verifying the full round trip including field mapping. Synthetic calls against each endpoint the integration depends on, so a silent deprecation surfaces as a failed probe instead of a failed business process. These are inexpensive to build and rarely built, because they require knowing what the integration is supposed to accomplish, which is exactly the knowledge that leaves with the original team.

Credentials outlive their owners

Every integration has credentials, and credentials have a lifecycle no one manages. API keys are created during implementation, embedded in configuration, and forgotten. The account that owns them may be a personal account of a former employee. When that account is deactivated during offboarding, or the key is rotated during a security review, the integration stops, and the connection between the credential and the business process it feeds has to be reconstructed under time pressure.

The failure is predictable enough that it should be designed for: integrations should authenticate as service identities owned by the organisation, with owners recorded, expiry dates in a calendar someone checks, and rotation rehearsed the way restores are rehearsed. Most organisations instead discover their credential inventory during the first incident.

Why the fragility compounds

Each integration in an enterprise estate adds the same profile of risk, and the risks multiply through the dependency graph. The order system depends on the inventory service, which depends on a supplier portal, which depends on a third-party logistics API. None of these dependencies are visible in any architecture diagram that is still current. When the deepest layer changes its behaviour, the failure surfaces three systems up, in a team that has no contact with the provider and no way to interpret the symptom.

This is why integration estates behave like infrastructure and are managed like projects. A project has an end date, a budget, and a handover. Infrastructure has an operator, a budget line, and a maintenance discipline. Integrations get the project treatment: built once, celebrated at launch, then orphaned. The organisation that treats its hundred integrations as a hundred small systems to operate, rather than a hundred completed projects, is the organisation that does not spend its Octobers in emergency mode.

What durable integrations do differently

The estates that stay healthy converge on a short list of practices. They pin behaviour, not just versions: contract tests that run against the live provider on a schedule, so drift is detected in days rather than discovered in quarters. They treat additive provider changes as events to assess, not noise to ignore, with a standing subscription to changelogs routed to a team rather than an inbox. They make every write path idempotent end to end, including the callbacks. They monitor business-level invariants, record counts and reconciliation totals, because those are the signals that survive every protocol change. And they keep an integration runbook that describes what the integration is for, which assumptions it rests on, and who owns it now.

None of this requires new technology, and none of it is glamorous. It is the unglamorous work that determines whether the agreement between two independently evolving systems is renewed deliberately every quarter, or renegotiated by accident during an outage. An integration does not age into stability. It either gets maintained as a living dependency, or it quietly becomes a liability with a launch date.