API Lock-In Is Worse Than Data Lock-In

Everybody worries about data lock-in and almost nobody worries about API lock-in, which is backwards, because API lock-in is the one that actually keeps you trapped. You can export data. It is a bounded, one-time job. But when your application is wired directly into a vendor's proprietary API, leaving is not an export, it is a rewrite of every place your code calls that vendor. Data lock-in costs you a migration. API lock-in costs you a re-architecture. That is the difference between leaving in a month and never leaving at all.

Why API lock-in is stickier than data

Data has a shape you can move. Rows, files, records: painful, but portable in principle. A proprietary API has no equivalent. When your code calls a vendor's specific endpoints, uses their specific SDK, and depends on their specific behavior, all of that logic is fused to the vendor. There is no export button for "the forty places in my codebase that call this service."

And it compounds silently. Every feature you build on the vendor's API deepens the coupling. A year in, the vendor is not a dependency you use, it is load-bearing structure. Ripping it out means touching everything built on top. This is the mechanism behind why serverless is the deepest lock-in: it is not the data, it is that your whole execution model is written in the vendor's dialect.

The tell: how much of your code knows the vendor's name

Here is a quick diagnostic. Search your codebase for the vendor's SDK import. If it appears in five places behind one adapter, you are fine, swapping the vendor is a contained job. If it appears in two hundred places scattered through your business logic, you are locked in no matter what the contract says. The vendor's name in your code is the real lock-in metric, and it has nothing to do with your data export rights.

This is also why multi-cloud is not the same as no lock-in. Running on two clouds while calling each one's proprietary APIs directly doubles your coupling instead of reducing it. The trap is the direct dependency, not the vendor count.

How to build so the API cannot trap you

The fix is old and boring and it works: put your own interface between your code and every vendor API. Your application talks to your abstraction. Your abstraction talks to the vendor. When you want to leave, you rewrite one adapter, not your whole app.

Define the interface around what your app needs, not around what the vendor offers. If you shape your abstraction to mirror the vendor's exact API, you have just moved the lock-in one layer down. Model it on your domain, so any vendor that can satisfy the interface is swappable. This is the same discipline as avoiding provider-specific infrastructure as code: keep the vendor-specific parts isolated and thin.

Prefer open standards for the things that have them. SMTP, S3-compatible object APIs, standard SQL, OpenTelemetry: where a real standard exists, code to the standard and the vendor becomes a runtime choice instead of a permanent commitment. Object storage you control through an S3-compatible interface is portable precisely because the interface is not owned by one vendor.

When accepting API lock-in is a reasonable trade

Sometimes a proprietary API is worth it. If a vendor's API gives you a capability you genuinely cannot get elsewhere and cannot build, and that capability is core to your product, coupling to it may be the right call. Just do it with eyes open: keep the coupling behind an adapter even then, so if the vendor dies or the capability commoditizes, you have a seam to cut. The goal is not zero lock-in everywhere. It is knowing exactly where you are locked in and keeping the cut points visible.

I run twenty companies on this principle. The data lives on infrastructure I own through HostSSH, and every external service sits behind an interface my code controls. Data I can always export. Coupling I have to design out before I build it in. Worry about the API first. The data will move. The rewrite is what keeps people stuck.