Control

Control is what APIs are really about, once you strip away the technical layer and look at what’s actually happening between the parties. An API is a contract, and like every contract, it encodes a power relationship. The provider decides what the consumer can access, what they can do with it, how much of it they can have, on what terms, and for how long. The consumer accepts those terms or walks away — and walking away is usually harder than it looks, because by the time you’ve built on an API you’ve already handed the provider a piece of your architecture. I’ve been calling this the politics of APIs since 2014, and the more I’ve watched the API economy mature, the more convinced I am that control — not technology, not innovation — is the organizing principle of the entire ecosystem.

The open-versus-closed question was where the politics first became obvious. I wrote about it in 2011 with what felt at the time like genuine ambiguity, because I could see real arguments on both sides. Open APIs give you reach and ecosystem leverage; closed APIs give you control and protection. What I didn’t fully appreciate yet was the paradox I’d identify later that same year: open APIs sometimes give content providers more control, not less, because when you define the terms of openness you also define the limits of it. “Open” with a terms of service is still conditional. The platform that publishes an open API but retains the right to revoke access, to rate-limit aggressively, to change the terms unilaterally — that platform is not open in any meaningful political sense. It’s just open enough to build a developer ecosystem, which it can then leverage and control. The open-versus-closed framing was always a red herring. The real question was always: who holds the power?

Terms of service are the most underexamined control mechanism in the entire API stack. I wrote in 2011 that API terms of service predict an unsure future — that reading the ToS carefully tells you everything about how a platform thinks about its developers. A ToS that reserves sweeping unilateral rights, that can be changed without notice, that prohibits competitive uses, that limits resale or sublicensing — these aren’t legal boilerplate, they’re a statement of power. The developer who reads them and integrates anyway is accepting a relationship where the platform can change the terms of their business at any time. By 2014 I was writing explicitly about the business and politics together — you can’t iterate on just the technology; the business model and the political structure of access are equally important, and they change constantly. By 2023 I was using the word “emphasis” deliberately — re-emphasizing the politics because the field kept trying to pretend it was purely technical.

The platform lifecycle story — the one that plays out over and over — goes like this: platform opens API, developers build on it, ecosystem grows, platform extracts value, developers get screwed. I wrote a deliberately satirical piece in 2016 about exactly this pattern — extracting as much value as you can from your API developers and then screwing them over in the end — because the cycle is so common it deserved a name. My 2017 framing was darker: slow-moving ransomware. The SaaS and API lock-in model increasingly resembles a long game of hostage-taking — get your customers and developers dependent, then gradually raise the price of exit. This isn’t unique to any single company; it’s the logic of platform capitalism applied to the API layer. The developer who builds on a platform and then discovers the platform intends to compete with them, or has decided their use case is no longer wanted, or is raising rates to the point of unviability — that developer has been subject to API control in its most extractive form.

Twitter is the canonical case study, and I’ve been writing about it since nearly the beginning. In 2011 I was already tracking the tension between Twitter’s API openness and the platform’s appetite for control — the early limits on third-party clients, the signals that Twitter wanted to own the user experience, the developer community’s growing unease. The arc played out over twelve years: Twitter built one of the great developer ecosystems, normalized third-party API access as a model for the whole industry, and then systematically dismantled it — competing with apps built on its API, restricting access, changing rules without notice, and eventually in 2023 pricing the API entirely out of reach for most of the developers who’d built on it. Reddit did the same thing in the same year. I wrote about Twitter and Reddit as canaries in the public API coal mine — warnings about what happens when a platform decides that the developer ecosystem it cultivated for years is now a cost center or a threat. What you build on a public API is always provisional, and the platform always holds the right to take it away. I documented the many ways APIs are taken away in 2019: deprecation, price increases, access restrictions, authentication changes, scope limitations, feature removal, and outright shutdown. Each of these is a form of control exercised over the people who built on the assumption that access was stable.

The data dimension of control is where the politics becomes most consequential for people beyond the developer community. Facebook Cambridge Analytica was the moment API data control became front-page news — and what it exposed wasn’t just Facebook’s failures, but the structural reality that API access to data at scale is effectively a form of power over the people whose data flows through it. I wrote in 2018 that the real question was whether Facebook even knew what API consumers were doing with user data, and the answer turned out to be that they’d designed a system for control of developer access while largely abandoning control over data use. By 2020 the FTC was suing Facebook, and APIs were explicitly at the center of that case — a platform that had used API access to consolidate market power while foreclosing it to potential competitors. Transparency about who has access to your social data through an API was something I called for in 2017; Cambridge Analytica proved that the absence of that transparency wasn’t just a governance failure, it was a harm at population scale. The right to an API key, which I wrote about in 2014 as a question about algorithmic organizing, is a political question about who gets to participate in the digital economy and on whose terms.

The regulatory response to platform control has been building for a decade, and healthcare is where it’s arrived most concretely. I wrote in 2020 about HHS and CMS finalizing rules that use APIs specifically as the mechanism for giving patients more control over their health data — mandating that insurers and providers expose APIs, that patients have the right to access their own records through those APIs, and that data blocking is prohibited. This is regulation using the API as the instrument of control restoration — taking a domain where platform and provider control had locked patients out of their own information, and using a legal mandate to open it. The same instinct drives open banking and the CFPB rules. Regulation is the blunt instrument that appears when market power and platform control have foreclosed other options.

The specification layer is where I’ve been watching a newer, subtler form of control play out. I wrote in 2025 about the politics of the API specification — about who controls the standards that define how APIs describe themselves and interoperate. OpenAPI, AsyncAPI, JSON Schema — these are governance infrastructure, and the politics of who steers them, who implements them, and whose interests they encode matters enormously. A standard shaped by the major cloud vendors, or by the tooling vendors with the largest commercial interests, encodes those interests into the technical substrate. The same year I was writing about business and politics together diminishing the potential of APIs as the next iteration of the web — the ways in which commercial consolidation and control instincts narrow the vision of what APIs could be from an open, interoperable, public-infrastructure model toward a collection of proprietary, extractive platforms dressed in the language of openness.

Against all this, I’ve been drawn to the alternatives — federated protocols, decentralized platforms, consent-forward architectures. When Twitter imploded I wrote about what Mastodon represented, and later about Bluesky, because these aren’t just technical choices but political ones: choosing a model where no single party controls the API, where the protocol is owned by no one, where access can’t be revoked by a corporate decision. Consent APIs — APIs designed from the ground up around explicit, user-held consent for data access — are the architectural antidote to the surveillance and control model that defaulted in the platform era. These are still minority positions in the API economy, but they matter as evidence that the current control regime is a choice, not a technical necessity.

The honest framing, the one I keep returning to, is that “what does open mean” is not a technical question. I wrote that explicitly in 2021: open in the world of APIs has been so thoroughly appropriated by commercial interests that the word itself has to be interrogated. An open API that can be closed unilaterally, that requires agreeing to terms that hand over your business model, that funds itself by surveilling the users of the apps built on it — that API is not open in any meaningful sense. Control is the persistent variable. Technology changes, platforms rise and fall, standards evolve, regulations arrive. But the question of who controls access, who sets the terms, who can take it away, and who bears the consequences when they do — that question doesn’t change. It’s the politics question, and it’s the question I’ve been trying to get the API industry to take seriously for fifteen years, with mixed results.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Control

References

Guidance Details

Explore more

Discover APIs