When the API Goes Dark: Building Products That Survive Their Own Dependencies

In early 2023, a wave of developers building on top of certain AI APIs woke up to a pricing change that doubled their per-token costs overnight. Some of them had built their entire product around a specific model's behavior. Their prompts, their UX, their cost structure — all of it was calibrated to an API they didn't own and couldn't control. When the terms changed, they had three options: absorb the cost, raise prices, or rebuild. None of those options were in the roadmap.

This is the third-party API trap. And in an era where building on top of external services is faster than ever — AI APIs, payment processors, communication platforms, data providers — it's a trap that's easier to fall into than it's ever been.

The Speed-Dependency Trade-off

There's a real reason teams build on external APIs. Integration is fast. You get capabilities in hours that would take months to build internally. For early-stage products, that speed is often the difference between validating an idea and running out of runway before you get an answer.

The problem isn't the decision to integrate. The problem is when the integration becomes load-bearing without anyone deciding it should be. The API call that started as a convenience becomes the core of the product. The external service's data model shapes your database schema. The provider's rate limits define your feature set. The vendor's roadmap becomes your roadmap.

At that point, you're not building on top of a dependency. You're building inside it.

The Acquisition Scenario

Acquisitions are the most dramatic version of this problem. A product you've built a deep integration with gets acquired by a larger company. The new owner has different priorities. The API gets deprecated, merged into a different product, or locked behind an enterprise contract that your pricing model can't support.

This has happened enough times that it should be a standard item on any integration risk checklist. Twilio acquired Segment. Salesforce acquired Slack. Stripe acquired Radar. Each of these acquisitions was ultimately fine for most users, but each of them also created a period of uncertainty where teams that had built deep integrations had to evaluate their exposure.

Less prominent acquisitions are riskier. When a smaller API provider gets acquired by a company whose core business isn't developer tools, the chance of that API surviving in its current form drops considerably. The acquirer didn't buy the API. They bought the team, or the customer base, or the technology. The API is an afterthought.

Feature Deprecations and the Quiet Sunsetting

Acquisitions are visible. Feature deprecations are often not. Providers quietly sunset endpoints, change behavior, or reduce functionality with a 90-day notice buried in a changelog that most teams don't read until something breaks.

This is particularly acute in the AI API space right now. Models get deprecated. Behavior changes between versions in ways that aren't always documented. A prompt that worked reliably six months ago may produce different outputs today because the underlying model was updated. If your product's value proposition depends on a specific model's specific behavior, you're exposed to a kind of drift that's hard to detect and harder to explain to users.

One developer tools company built a code review feature on top of a specific GPT model version. When that version was deprecated in favor of a newer model with different characteristics, their carefully tuned prompts started producing inconsistent results. The feature didn't break — it just got worse in ways that were hard to quantify. Users noticed before the team did.

The Abstraction Layer Is Not Optional

The standard advice here is to build an abstraction layer between your product logic and the external API. This advice is correct and consistently ignored because it feels like premature engineering when you're moving fast.

But the abstraction layer doesn't have to be elaborate. At its simplest, it's a module or service that owns the relationship with the external API — translating your internal data model into whatever the API expects, and translating the API's response back into your internal model. Your product logic never talks to the API directly. It talks to your abstraction.

When the API changes, you update the abstraction. Your product logic stays the same. When you want to swap providers, you write a new adapter for the abstraction. Your product logic stays the same.

This sounds obvious. It becomes less obvious at 2 a.m. during a sprint when you're trying to ship a feature and the path of least resistance is to call the API directly from the component that needs the data. That shortcut, taken once, gets repeated. The direct API calls spread through the codebase. The abstraction opportunity closes.

Fallback Systems and Graceful Degradation

For integrations that are genuinely critical — payment processing, identity verification, core data providers — the abstraction layer should come with a fallback strategy.

What does your product do when the API is unavailable? If the answer is "it breaks," that's a dependency, not an integration. If the answer is "it degrades gracefully and queues the work for when the service recovers," that's a product that can survive its own dependencies.

For AI APIs specifically, multi-provider strategies are becoming standard practice among teams that have been burned. The pattern: define the capability you need at the abstraction layer, implement it for your primary provider, and maintain a secondary implementation for a different provider. Route traffic to the secondary when the primary is unavailable or when costs exceed a threshold. This adds complexity, but it also means a pricing change or an outage at one provider doesn't take your product offline.

Knowing Which Integrations Are Worth the Risk

Not every integration deserves the same level of defensive engineering. The question to ask is: if this API disappeared tomorrow, how long would it take to ship a replacement, and what would it cost?

Low-stakes integrations — analytics, logging, non-critical notifications — can afford shallow abstraction. If the provider goes away, you swap it out over a sprint. The cost is low.

High-stakes integrations — anything that touches your core value proposition, your billing, your data — deserve deeper investment in abstraction and fallback. The cost of getting it wrong is high enough to justify the upfront work.

The integrations that catch teams off guard are the ones that start low-stakes and drift into high-stakes without anyone noticing. An analytics integration that gradually becomes the source of truth for business decisions. A communication API that becomes the only channel for critical user notifications. A data provider whose output becomes embedded in your own database schema.

Watch for that drift. When an external API starts shaping how you think about your own product, it's time to ask whether you've handed over more control than you intended.

Own Your Core

The early adopter advantage isn't just about shipping fast. It's about shipping smart — knowing which bets are worth making and which shortcuts create structural risk.

Building on external APIs is a good bet. Building your product's identity inside an external API is a different bet entirely. The teams that navigate this well aren't the ones who avoid integrations. They're the ones who know exactly where they end and the API begins.