Why Apps Stop Working a Few Months After Launch

An integration that works at launch and breaks six months later is almost never a code problem — it's a contract problem. The upstream API added a field, deprecated an endpoint, or changed a rate limit, and nothing in our system was watching for it.

We've moved toward treating every third-party integration as an assumption that needs a test, not a fact. Schema validation on every response, alerting on unexpected fields, and a documented fallback for when the integration goes down entirely.

The integrations that have held up longest are the ones we built assuming the other side would eventually change without telling us.

The most common version of this failure is the silent field addition. An API adds a new field to its response, and our code — written to read specific keys off a JSON object — keeps working fine, because nothing about adding a field breaks existing consumers. The problem shows up later, when a downstream system that expects a fixed schema starts choking on the extra data, or when the vendor removes a field we never explicitly declared as required and our code null-references without warning.

Rate limits are the second pattern, and they're worse because they're load-dependent. An integration built and tested against a vendor's sandbox, or against production at low volume, can look completely healthy for months and then start failing the moment real usage crosses a threshold nobody tested against. We ask, for every integration, what the vendor's documented limit is and what happens on the client side when we hit it — not in theory, but by deliberately triggering it in a test environment.

Deprecation notices are the failure mode teams are worst at catching, because they usually arrive as an email to whoever set up API access originally, who may not work there anymore eighteen months later. We've started subscribing integration owners — a role, not a person — to every vendor's changelog and status page, and treating a deprecation notice with the same urgency as a security advisory.

Schema validation on every response sounds like overhead until you've been burned once. We now validate the shape of every third-party response against an explicit schema before using it, and alert loudly the first time a field is missing or a type changes, rather than letting the code silently coerce or ignore it. That alert firing in a staging environment during a vendor's rollout is worth more than any amount of manual monitoring.

The fallback question is the one people skip because it feels like planning for a problem that isn't happening yet. But a payment processor, an auth provider, or a shipping API going down for twenty minutes is not a hypothetical — it's a Tuesday. We define, for every integration we consider critical, what the system does when it's unavailable: queue and retry, degrade gracefully, or fail loudly and visibly rather than silently dropping data.

The integrations that have survived multiple years in production without a surprise outage are the ones we stopped treating as finished the day they shipped.