Interoperability is the promise at the heart of APIs and the political battleground where that promise is constantly contested. The whole point of an API, in principle, is interoperability — different systems, built by different parties, able to exchange data and work together. That’s the dream: a web of interconnected systems that speak to each other, where your data moves freely and your tools work with everyone’s tools. But interoperability is also a threat to the business models that depend on lock-in, which is why the politics of interoperability are so fierce. Every platform that benefits from keeping you trapped has an interest in limiting interoperability, and every challenger and every consumer has an interest in expanding it. The history of API interoperability is the history of this tension — between the genuine technical possibility of systems working together and the commercial and political forces that resist it.
The hard truth I’ve had to confront, and which I’ve stated bluntly, is that interoperability is often more aspiration than reality. I wrote in 2019 that API interoperability is a myth — a deliberately provocative framing of an honest observation. The technical capability for interoperability exists, but the commercial reality is that most companies don’t actually want it. I wrote in 2013 that the API space often seems to be more about money, intellectual property, and competition than about interoperability, and in 2018 that not all companies are interested in the interoperability that APIs bring. The reason is simple: genuine interoperability reduces lock-in, and lock-in is profitable. A company that makes it easy for you to move your data and switch to a competitor is giving up a powerful retention mechanism. So while APIs make interoperability technically possible, the politics and economics of most businesses push against actually delivering it. The myth isn’t that interoperability is impossible; it’s that the market will produce it voluntarily.
The “embrace, extend, exterminate” pattern is the dark playbook of interoperability politics, and I’ve written about it as it plays out in the API world. The classic Microsoft strategy — embrace a standard, extend it with proprietary additions, and use those extensions to exterminate the competition and lock users in — applies directly to APIs. A platform can support an interoperability standard just enough to win adoption, then add proprietary extensions that become essential, then use the resulting lock-in to eliminate the interoperability the standard was supposed to provide. This is interoperability as a competitive weapon rather than a public good — using the appearance of openness to achieve the reality of control. Recognizing this pattern is essential to understanding why so much nominal interoperability fails to deliver real freedom: the interoperability is often deliberately incomplete, extended just enough to capture rather than to liberate.
The copyright fight is where interoperability’s political stakes reached their peak, because Oracle v. Google was fundamentally about whether interoperability would remain legal. If API interfaces could be copyrighted, then reimplementing an API to achieve interoperability — building a compatible system that speaks the same API — would require permission from the original API’s owner. That would have been catastrophic for interoperability, because the freedom to reimplement an interface is exactly what allows competing and compatible systems to exist. I followed the case all the way to the Supreme Court, signing the EFF briefs, because the stakes were nothing less than whether interoperability would remain a right or become a privilege granted by incumbents. The eventual ruling that API reimplementation is fair use preserved the legal foundation of interoperability. Without that outcome, the politics of interoperability would have shifted decisively toward the platforms, who could have used copyright to lock up their interfaces and prevent compatible competition.
Regulation is the political force that delivers interoperability when markets won’t, and this is the most important pattern in the field. Because voluntary interoperability runs against business incentives, the interoperability that actually happens at scale is often mandated. Open banking and PSD2 in Europe forced banking interoperability — requiring banks to expose APIs so that consumers’ financial data could move and third parties could build on it. The HHS and CMS healthcare rules forced healthcare interoperability through FHIR, mandating that providers and insurers expose APIs so patients could access and move their health data. The White House’s interest in data portability, which I wrote about in 2016, was government recognizing that data portability and interoperability are consumer rights that the market won’t deliver on its own. The lesson is consistent: in regulated industries where incumbents control critical data, interoperability is achieved through legal mandate, not market goodwill. Regulation is how society forces the interoperability that benefits the public against the commercial interests that would prevent it.
The federated alternative is the most hopeful development in interoperability politics, and I’ve followed it with real interest. Mastodon and the ActivityPub protocol, which I wrote about as opening the age of federated APIs, represent a fundamentally different model: interoperability built into the protocol from the start, where no single party controls the network and the ability to interoperate is the default rather than a grudging concession. Federated systems are interoperability by design — your data and your social graph can move between instances because the protocol guarantees it. This is the architectural answer to the politics of lock-in: rather than depending on a platform’s goodwill or a regulator’s mandate, you build systems where interoperability is structural and can’t be unilaterally revoked. The loose federation of API standards I wrote about in 2023 points the same direction — interoperability achieved through shared, open standards that no single party can capture and lock down.
Where I’ve landed is that interoperability is a political achievement, not a technical given, and that’s the essential thing to understand about it. I wrote in 2026 about the importance of an API consumer interoperability mindset — because consumers have to actively demand and defend interoperability, since the market won’t provide it for free. The technical capability for systems to work together has existed for a long time; APIs make it straightforward. But whether that capability is actually realized depends on a constant political struggle between the forces of lock-in and the forces of openness. Sometimes openness wins through regulation, as in open banking and healthcare. Sometimes it wins through legal protection, as in the Oracle v. Google ruling. Sometimes it wins through architecture, as in federated protocols. And often it loses, as platforms embrace-extend-exterminate their way to control while claiming to support open standards. Interoperability is the promise of APIs, but it’s a promise that has to be fought for, mandated, protected, and architected, because the commercial gravity of the digital economy pulls relentlessly toward the lock-in that interoperability threatens. The dream of systems freely working together is real and achievable — but only as a political accomplishment, never as a default the market will hand us.
References
- The API Space Often Seems To Be More About Money, Intellectual Property, And Competition Than Interoperability Sometimes
- Embrace, Extend, And Exterminate In The World Of APIs
- The White House Wants Our Thoughts On Data Portability
- Healthcare API Interoperability At HL7 FHIR DevDays In Amsterdam
- What Is Open Banking In The UK
- Not All Companies Are Interested In The Interoperability That APIs Bring
- API Interoperability Is A Myth
- API Copyright Heading To The Supreme Court
- HHS And CMS Finalizes Rules To Provide Patients More Control Of Their Health Data Using APIs
- Mastodon Opening The Age Of Federated APIs
- A Loose Federation Of API Standards
- An API Consumer Interoperability Mindset
