Access is the foundational question of every API. Before anyone can consume data, invoke a capability, or integrate a resource, someone had to decide who could reach it and under what conditions. I’ve been writing about API access since 2010, and the story is not primarily a technical one. The technical layer — API keys, OAuth tokens, rate limits, RBAC — is real and important, but those mechanisms almost always express prior decisions about power, economics, trust, and rights. Access is where the politics of APIs become visible.
When the first generation of commercial web APIs launched in the early 2000s — Salesforce in 2000, eBay and Amazon shortly after — access was simply a matter of registering for credentials. The default was relatively open. Salesforce gave enterprise customers API access as part of the deal. Amazon Web Services charged per API call. eBay gave developers keys to build on top of marketplace data. The emerging norm was that access was good, that more developers building on your platform was better than fewer, and that the goal was to attract integration.
That model created the API key as the basic primitive of access control. A key identified who was calling, gave the provider a way to track usage, and provided a handle for enforcement. I wrote as early as 2011 that I understood why providers required keys — knowing who has access and how they’re using it is legitimate. What I struggled with was the instinct to go further, to use those keys not just to identify developers but to artificially limit what they could do. Rate limiting that protected infrastructure made sense. Rate limiting that protected data as a competitive asset was a different thing.
The access model that mattered most for the early API space was OAuth. Google’s adoption of OAuth 2.0 in 2011 was a signal moment — here was a standard that didn’t just authenticate a developer application, but gave end users control over what that application could see and do. OAuth transformed access from a two-party agreement between provider and developer into a three-party relationship that included the person whose data was actually being accessed. That shift — giving users the ability to grant and revoke access without surrendering their credentials — was one of the genuinely empowering things the API space produced. It also created the infrastructure for a decade of arguments about what it meant when users “authorized” access and whether platforms honored the spirit of that authorization.
By 2012, the cracks in the open-access model were showing. Twitter’s rate limits, introduced in 2007 ostensibly to protect server capacity, had evolved over five years into something qualitatively different. The restrictions weren’t about load anymore — they were about protecting an increasingly valuable data asset from third-party applications that Twitter now saw as competitors. I wrote about this in June 2012: Twitter had restricted access to a firehose that developers had built entire businesses on, not because of infrastructure constraints, but to funnel traffic toward their own clients and their advertising business. The same data was still there. The decision about who could reach it had changed. That is what access politics looks like in practice.
Facebook’s trajectory followed a similar arc, but with higher stakes because the data was more personal. The Facebook Graph API gave developers rich access to social graph data, and an ecosystem of applications, analytics tools, and research projects built on top of it. Then came the Cambridge Analytica revelations, and Facebook tightened access dramatically. The restrictions were politically necessary and in some ways correct — the prior access regime had been genuinely dangerous. But the tightening also swept up legitimate researchers, journalists, and independent developers who had no malicious intent. When I requested access to Facebook’s threat intelligence API in 2017, I was declined because they were “focused on solving the challenges of companies with dedicated abuse detection teams.” The gatekeeping that protects users from bad actors also protects platforms from scrutiny.
While platform access was contracting in one part of the conversation, it was expanding in another: government data. The open data movement of the early 2010s produced a wave of government APIs, and with them a new set of access questions. Should all government data be free and open? Who bears the cost of hosting and serving it at scale? In 2013 I wrote about the tension in charging for higher levels of access to government data — the basic case being that while open access is the right default, high-volume automated consumption has infrastructure costs that someone has to cover. The Recreation Information Database API, which managed access to federal recreation resources, implemented a tiered model in 2015: nominal requests were free, high-volume commercial consumption carried a fee. That was a reasonable and defensible approach to balancing public good with operational reality.
The internal-access dimension of APIs was underappreciated for years. Most of the public conversation was about external developer ecosystems, but some of the most important access dynamics were inside organizations. Amazon’s internal mandate — that all service-to-service communication had to go through APIs — wasn’t about developers. It was about making enterprise resources self-service and observable. I wrote in 2014 that explaining APIs to senior leadership worked best when you framed it that way: APIs make company resources available without the IT bottleneck. Access to internal data and capabilities, on demand, with audit trails, without ticket queues. The same logic applied to government: the conversation about open data was dominated by public access, but the internal access story — agencies sharing data with each other via API rather than through manual processes — was just as important and got far less attention.
The tiered access model matured through the mid-2010s as providers figured out that public-versus-private wasn’t a fine enough distinction. I moved from two buckets (public, private) to three (public, partner, internal) to something more granular — different tiers for verified vs. unverified developers, different plans by use case, different limits by volume. Factual implemented verified vs. unverified tiers in 2016: 100 calls per day unverified, 10,000 after you proved who you were and what you were building. Google Adwords had a basic tier and a standard tier. The sophistication of the access layer became a proxy for the maturity of the API program overall.
The freemium model — which had been 3Scale’s contribution to the access conversation — came under pressure around 2016. I wrote that year that I was hearing a lot more talk about restricting or eliminating free tiers. The reasons were commercial: free users don’t convert to paid, they consume support resources, they’re at odds with sales teams trying to close enterprise deals. This was a real tension, but I was skeptical of the conclusion. Freemium access was how the developer ecosystem had been built. Restricting it to drive enterprise sales was a short-term calculation that eroded the long-term value of having a large, active community. By 2019, I was writing that APIs I couldn’t pay for access to — GitHub, Twitter, Facebook — frustrated me almost as much as APIs that refused to offer paid tiers at all. The problem wasn’t freemium or paid; it was opacity. If you can’t apply a unit of value to your API resources and make them available in a straightforward way, it suggests you’re not actually treating the API as a product.
Access as a rights question entered the conversation through healthcare and education. HIPAA’s right of access provision — the right of patients to access their own personal health information — created a direct mandate for patient-directed APIs. The argument was simple: this data is about you, you have a legal right to it, and APIs are the modern mechanism for exercising that right. The same logic applied to student data. FERPA gives students rights over their own educational records, and the question I was asking by 2015 was why those rights weren’t being operationalized through APIs. Self-service API access to your own data, controlled by OAuth so you decide who else can see it, is not a radical ask — it’s what the law already says you’re entitled to.
The transparency dimension of access became important as the data economy matured. It wasn’t enough to know that you had access to an API; the question of who else had access became consequential. I wrote about Apply Magic Sauce in 2017 as an example of the right model: they published a complete, public list of every organization authorized to use their platform for commercial purposes. 100% transparency of every partner, customer, and developer with access to personal data. That’s a high bar, but it’s the right direction. Law enforcement access to social platform data via OAuth and API was another access transparency question I was writing about in 2016 — the technical mechanism for police access to platform data should be visible and auditable, not opaque.
By 2025 the framing had come full circle. I was writing that 100% of access to enterprise digital resources should go through APIs — not some resources, not the external ones, all of them. Databases, files, backend systems, everything. Not because APIs are a religion, but because a unified API surface is the only way to get a consistent access, control, observability, and security layer across an entire enterprise. The access question that started as “should we give developers API keys” had grown into “should every interaction with digital resources in the organization be mediated by a programmable interface.” The answer is yes, and the reason is the same as it always was: access without visibility is just hope. APIs make access observable, governable, and accountable. That is why the access question has always been, at its core, a governance question.
References
- Why Do We Limit API Access For Developers
- Twitter Continues To Restrict Access To Our Tweets
- Charging For Higher Levels Of Access To Government Data And APIs
- When You Are Ready For A Nuanced Discussion About Who Has Access To Your API, I Am Here
- I Got A Response Regarding My Facebook Threat API Access
- Paying For API Access
- 100 Percent Of Access To Enterprise Digital Resources Should Be Via APIs
