What to Do When a Third-Party API Kills Your Core Feature Overnight

At some point, almost every SaaS founder discovers that the third-party API sitting at the heart of their product is not as stable as they assumed. The pricing changes with three weeks’ notice. The endpoint they rely on gets deprecated. The vendor gets acquired, pivots, or simply decides your use case is no longer supported. When that happens, you’re not dealing with a technical problem – you’re dealing with a business continuity crisis, and most products aren’t built to handle it gracefully.

We’ve seen this enough times to have a strong opinion: the way you integrate external APIs in the first year of building almost always determines how badly this hurts when it goes wrong. And it will go wrong.

The Dependency Problem Most Founders Don’t See Until It’s Too Late

Here’s the trap. You’re building fast, validating quickly, and the right move at MVP stage is often to use whatever API gets you to market fastest. That’s correct. The mistake isn’t using third-party APIs – it’s building as if those APIs are permanent infrastructure rather than borrowed ground.

The distinction matters architecturally. If your application code calls an external API directly, scattered across ten different service files, with no abstraction layer in between, then the API is your architecture. Swapping it out later means touching every one of those call sites. For a small codebase that’s annoying. For a product that’s been in production for two years, it can be a four to six week rebuild under pressure.

The mistake we see most often is what we’d call tight coupling at the wrong layer – business logic that’s written around the specific response shape of a vendor’s API rather than around the domain concepts of the product itself. A payments feature written around Stripe’s exact response objects. A mapping feature that assumes Google Maps’ specific geocoding format. It works perfectly until it doesn’t.

The Adapter Pattern: Boring, Effective, Worth Doing Early

The standard architectural response to this problem is the adapter pattern, and it’s not exotic – it’s just disciplined. The idea is simple: you write your own internal interface that describes what your application needs, and then you write an adapter that translates between that interface and whatever third-party API you’re currently using.

Your application code talks to your interface. It has no idea what’s sitting behind it. If the vendor changes, you swap the adapter, not the application.

In practice, for a SaaS with a single developer or a small team, this adds maybe half a day to a week of work upfront depending on the complexity of the integration. It’s almost never prioritised in a crunch. But when we build new products at Amora, we enforce it as a default for any integration that touches core user flows – payments, communications, data enrichment, identity, mapping. The ones where breakage would be immediately visible to users.

For integrations that are peripheral – a third-party analytics sink, a logging service, a non-critical enrichment API – we’re more pragmatic. Direct integration is fine. The question to ask is: if this vendor disappeared tomorrow, could we ship a replacement within a day? If yes, coupling is acceptable. If no, abstract it.

When the API Doesn’t Die – It Just Gets Expensive

The scenario founders tend to prepare for least is the pricing change – specifically the kind where the API doesn’t break, it just becomes uneconomical. We saw this play out across a range of products after several major AI APIs shifted to consumption-based pricing that scaled in ways founders hadn’t modelled.

Suddenly a feature that cost roughly $0.002 per call at launch was costing $0.04 per call. At low volume, irrelevant. At 50,000 calls a day, that’s a meaningful line item that didn’t exist in the original unit economics.

This is a product architecture problem as much as a cost problem. A few things that genuinely help:

• Cache aggressively where the data allows it. If you’re calling an external API for data that doesn’t change per-request – reference data, classifications, enrichment on static records – cache the result. Even a short TTL can dramatically reduce call volume.
• Track per-feature API costs in production. Not just aggregate spend – cost per feature, per user tier, ideally per plan. If you don’t have this visibility you can’t make sensible pricing decisions when vendor costs change.
• Model the unit economics at 10x and 100x current volume before you ship. We do this as a standard part of architecture review for any AI-heavy feature. The numbers that look fine at 1,000 users often look broken at 100,000.
• Understand your contractual position with the vendor. Enterprise tiers often lock in pricing for 12-24 months. If you’re on a growth trajectory, locking in pricing while it’s still cheap is worth the conversation.

Building a Rapid Response Playbook Before You Need It

When an API change hits in production, the worst time to figure out your options is under pressure with users affected. The teams that handle it well have already thought through the answer to a few key questions.

Who are the realistic alternative vendors for each of your critical integrations? Not a vague awareness that alternatives exist – an actual shortlist with notes on what the migration would involve. For payments, you probably know Stripe and Pin Payments. For maps, you’ve likely thought about Mapbox. But for the more specialised APIs – identity verification, sector-specific data feeds, AI inference endpoints – founders often have no idea what a migration would look like until they’re forced to find out quickly.

We recommend keeping a simple integration register. It doesn’t need to be elaborate – a shared doc with a row per integration, covering: what it does, which features depend on it, who the alternative vendors are, rough migration effort, and who owns it. Update it when integrations change. When something breaks or reprices, you open the register and the conversation is already half done.

The other thing worth having is a feature flag system that lets you disable or degrade a feature that depends on a broken API without taking the whole product down. If a user hits a failure in a non-critical feature and gets a “temporarily unavailable” message rather than an error page, that’s a meaningfully better experience – and it buys you time to fix the underlying problem properly. This is not hard to implement. It’s just almost never done until after the first bad incident.

When the Right Answer Is to Stop Depending on the API at All

Some integrations start as external dependencies and graduate to something worth owning. Not because building it yourself is inherently better, but because the risk profile of the dependency has changed.

Consider a SaaS that built its core classification feature on a third-party AI API. That worked well at MVP stage. Two years in, with a significant user base and clear training data of their own, the calculation looks different. The external API is now a cost centre, a latency source, a privacy consideration, and a single point of failure – and the product team has enough labelled data to fine-tune a smaller, cheaper model they could run themselves or on infrastructure they control.

The decision to internalise an API dependency isn’t usually about capability – it’s about whether the risk and cost of the dependency now exceeds the cost of replacing it. That crossover point is different for every product. But it’s worth revisiting the calculation annually, not just when something breaks.

If you’re running a product with significant AI inference costs and you haven’t modelled what a fine-tuned open-source model would cost to run on your actual call volume, that’s a gap worth closing. The answer might be “still cheaper to use the API” – but you should know that, not assume it.

What to Actually Do This Week

If your product is live and you’ve never audited your third-party API dependencies from a risk perspective, here’s a practical starting point:

1. List every external API your product calls in production. Include the ones that feel invisible – auth providers, email services, monitoring tools that you’d notice immediately if they stopped working.
2. For each one, answer two questions: what breaks if this disappears tomorrow, and how long would a migration realistically take?
3. Sort by impact and migration effort. The high-impact, high-effort ones are your risk register.
4. For the top two or three, spend an afternoon researching alternatives and roughing out what a migration would involve. Write it down.
5. If any of those integrations are tightly coupled through your codebase rather than abstracted, schedule the refactor before it becomes urgent.

None of this is glamorous work. It doesn’t ship features. It doesn’t show up in a roadmap demo. But it’s the kind of thing that separates products that handle incidents cleanly from ones that have a bad week in front of their users.

If you’re building something new and want to get the architecture right from the start – particularly around AI integrations where the vendor landscape is still shifting – talk to Amora about your build. Getting the dependency model right in the first four weeks is a lot cheaper than untangling it at month eighteen.