Your API is becoming a dependency you don't control

Your product integrates a payment provider, a identity service, a maps API, a CRM, a government registry. Each integration started as a ticket: connect, authenticate, ship. Over time the integration becomes load-bearing. Customer journeys depend on it. Revenue depends on it. Nobody updated the dependency register because APIs feel lighter than servers — until the vendor changes pricing, deprecates a field, throttles your traffic, or has an outage that becomes your outage.

An API dependency is still a dependency. You do not control its availability, its roadmap, its rate limits, or its definition of breaking change. You control your side of the contract — and often not even that, if the vendor interprets terms differently after an acquisition.

Constrange treats external APIs as architectural components with failure modes, not as glue code. The question is not whether to integrate. It is whether you know what you have outsourced — and what you will do when the API behaves unlike the documentation.

Contracts are promises with an asymmetry

API documentation describes happy paths. Production describes rate limits, ambiguous error codes, undocumented fields, and behaviour changes without version bumps. Your contract tests may pass while your customers fail because the vendor rolled out a change to ten percent of traffic first.

Versioning is a lifecycle, not a header

Teams pin a version in config and forget it. Vendors sunset versions on calendars that do not respect your change freeze. Fields marked optional disappear. Semver on the label does not guarantee semver in behaviour. If you have not rehearsed migration across API versions, you do not have a version strategy — you have a hope.

• Deprecated endpoints still in production at sunset minus thirty days
• Breaking changes announced in a blog post, not a changelog
• Sandbox behaviour that does not match production edge cases
• Multiple teams on different versions of the same vendor API
• No owner for vendor release notes review

Rate limits are architecture

Rate limits are not edge cases. They are capacity boundaries on your critical path. A burst of legitimate traffic — campaign, batch reconciliation, retry storm — can convert success into four-twenty-nine responses that cascade into your own timeouts. Designing without rate limit headroom is designing for silent failure at scale.

Read limits early. Model your peak honestly, including retries. Negotiate limits before launch, not during incident. Cache where terms allow. Queue where latency permits. Fail gracefully where it does not — with a customer message that is not 'unknown error'.

1. Per-client limits lower than your peak concurrent users
2. Daily quotas exhausted by batch jobs sharing the same key
3. Different limits per endpoint; only one documented
4. Hard stops without graceful degradation path
5. Retry logic that burns quota faster than progress

Vendor change is a deployment you did not schedule

Acquisitions, pivots, and policy shifts

Vendors get acquired. APIs get bundled. Free tiers disappear. Data handling changes. A region stops being served. Your architecture assumed stability because the SDK was convenient. Convenience is not control. When the vendor's strategy moves, your roadmap moves with it — unless you built abstraction and exit paths early.

Cascading failure through the API boundary

Your service waits on the vendor. Your UI waits on your service. The vendor times out slowly. Your thread pool fills. Unrelated features stall. The API dependency is one hop but the blast radius is your platform — because shared connection pools and synchronous calls were easier than isolation.

Treat external calls like any unreliable dependency: timeouts shorter than the user's patience, bulkheads so one integration cannot exhaust workers, circuit breakers with observable state, and async paths where the business allows.

“You outsourced the integration. You did not outsource the outage. Customers still call you when the vendor disappears.”Constrange

What dependency really means on the diagram

A dependency is anything whose failure stops your outcome. APIs belong on the diagram with the same seriousness as databases — including RTO assumptions, fallback modes, and named owners who read release notes. If the only documentation is 'we use Stripe' in a README, the organisation does not understand its dependency graph.

• No runbook for vendor outage beyond 'wait'
• Single API key shared across environments
• Secrets in code without rotation rehearsal
• Compliance assumed because vendor is 'certified'
• No alternative path priced or prototyped

Designing for APIs you do not control

Abstraction without illusion

Wrap vendor APIs behind an internal interface that reflects your domain, not theirs. This is not denial — it is damage containment. Migrations become feasible. Tests mock your interface. Vendor quirks stay in one module instead of spreading through the codebase.

Exit options before you need them

Two vendors is expensive. One vendor with no exit is more expensive when they change terms. Prototype the second path before the contract renewal negotiation. Know what data you can export and how long migration takes — in weeks, not slides.

Operational habits for API dependencies

1. Assign an owner to each critical vendor integration — release notes, limits, incidents.
2. Contract test against vendor sandboxes on every deploy; record drift.
3. Track quota usage like CPU; alert before hard stops.
4. Rehearse vendor outage quarterly; measure customer impact.
5. Maintain an integration register linked to architecture diagrams.

These habits are boring. So are most production incidents that started with 'the API changed'.

Integration registers nobody maintains

Enterprise architecture repositories love boxes. They rarely list which external API keys exist, who rotates them, or which customer journeys fail when a vendor degrades. The register rots because integrations feel small at go-live and load-bearing at scale.

Constrange starts dependency reviews with production config and finance invoices — not diagrams. Keys, quotas, and renewal dates tell the truth about coupling. If only one engineer knows the integration exists, you have a bus factor on your critical path.

1. Inventory every external API on the revenue and fulfilment path.
2. Assign named owners — not 'platform team' generically.
3. Link each integration to customer-visible outcomes and SLAs.
4. Review vendor terms annually, not only at procurement.
5. Archive post-mortems where vendor behaviour was root cause.

Questions for your next dependency review

• Which customer outcomes stop if this API is down for four hours?
• Who read the last vendor changelog — and when?
• What happens at rate limit during our honest peak?
• How long to migrate to an alternative — tested, not estimated?
• Is this call synchronous on a path that cannot afford vendor latency?

APIs accelerate delivery. They also concentrate risk. Naming that risk is how engineering keeps control of outcomes it no longer fully controls at the wire level.

Your API is becoming a dependency you do not control the moment customer value flows through it without a owner, a fallback story, and an honest bill for vendor behaviour. Integrate deliberately — or inherit someone else's roadmap as your incident queue.

Control what you can: timeouts, isolation, abstraction, exit rehearsal, and honest customer messaging. Leave the vendor's roadmap on their slide deck — not unexamined on yours.

Dependency reviews that start in production — keys, quotas, invoices, incident history — finish faster than reviews that start in the architecture repository. The repository shows intent. Production shows coupling.

The contract is not the relationship

Legal terms, support tiers, and roadmap calls matter as much as OpenAPI specs. A breaking change announced in a changelog is still a breaking change if your abstraction layer never isolated consumers from field renames. Engineering control ends where commercial relationship begins — unless you have rehearsed what happens when the relationship shifts.

Procurement often optimises for unit price. Operations pays for coupling in incidents, rewrites, and customer apologies. Name that trade explicitly before the API becomes load-bearing.