Openness, Then Walled Gardens
Fifteen years ago, while building Heroku's V3 API, the guiding target was straightforward: make the public interface capable of running the company's own dashboard, free of private endpoints. The approach proved its worth when an unaffiliated developer built Heroku's first iOS app using only the public API—no feature requests, no back-channels.
That standard of openness may seem excessively idealistic in retrospect. But it reflected a particular moment in 2011, when the API felt like an engine for web-wide interconnectivity. Several major platforms embodied the ethos:
- Facebook's original Open Graph API, released in 2010, gave third parties remarkable visibility into platform data.
- Twitter's API was nearly wide open, permitting username/password authentication and broad data access without OAuth tokens.
- GitHub produced notably thorough API design work and experimented with ahead-of-its-time concepts like hypermedia and HATEOAS.
Artifacts of that era persist. Hit the root GitHub API and you'll still find a decade-old list of hypermedia links intended for client traversal:
$ curl https://api.github.com | jq
{
"current_user_url": "https://api.github.com/user",
"current_user_authorizations_html_url": "https://github.com/settings/connections/applications{/client_id}",
"authorizations_url": "https://api.github.com/authorizations",
"code_search_url": "https://api.github.com/search/code?q={query}{&page,per_page,sort,order}",
"commit_search_url": "https://api.github.com/search/commits?q={query}{&page,per_page,sort,order}",
"emails_url": "https://api.github.com/user/emails",
"emojis_url": "https://api.github.com/emojis",
"events_url": "https://api.github.com/events",
...
Those features weren't the product of long roadmap discussions—they came from a couple of engineers with strong convictions, shipping without much ceremony. A mix of goodwill and commercial hopes fueled the movement. Platforms expected third-party extensions to enrich their products, drive retention, and broaden reach. Sites like the now-defunct ProgrammableWeb chronicled this expansion, promoting the belief that all platforms would soon expose full programmatic access.
Retrenchment
The trajectory reversed. APIs broadened, then constricted, and the ecosystem contracted with them:
- Twitter's once-generous API tightened as the company sought ad revenue; firehose access was revoked and third-party clients were gradually locked out.
- Post-Cambridge Analytica, Facebook's Graph API effectively moved from an open platform to a gated review process after a single app exfiltrated data on millions of users.
- Instagram took the most extreme route, retiring its public API altogether when it recognized the inherent value of its ad inventory.
- GitHub's API stayed comparatively accessible but added mandatory authentication and more aggressive rate limiting to curb abuse and manage operational load.
The contributing drivers looked different at each company—abuse, monetization pressure, competitive or privacy risk—yet the pattern was uniform. Walls went up across the industry. APIs were dialed back to developer-for-developer platforms where users were already customers, such as Stripe, Twilio, and Slack. When new consumer apps emerged, nobody presumed they'd come with an API worth building on.
A different kind of API demand
For years, the API economy played out mostly in developer tools. Services like GitHub and Stripe thrived on programmatic access, but consumer platforms had little reason to expose one. Using Twitter meant Twitter.com; Facebook meant the Facebook app. APIs were a nice-to-have for most companies, rarely a deciding factor for users.
That started to change around mid-2025. Large language models became genuinely useful not just as conversation partners but as tools that can take actions. A model that can generate a Kubernetes manifest is interesting; one that can provision an EKS cluster through awscli and push your first production deploy is transformative. The shift is that an API stops being a liability and becomes a way to let an agent do work on your behalf. In a market full of similar products, the presence of a good API may soon be the deciding factor.
Banking on an API
Consider the average bank account. The feature set hasn't changed much in decades. Transfers between internal accounts take 1-5 business days. Even modern conveniences like MFA are gated behind vendors that have paid for placement. These institutions have had no real reason to offer APIs. People rarely switch banks, and new entrants face steep regulatory barriers.
But the ritual of logging into two separate portals, passing CAPTCHAs, and re-authenticating just to move $100 between your own accounts is exactly the kind of friction an LLM agent could eliminate. The desired experience: tell an agent to move money from one account to another, and have it happen. Good LLMs might already be able to reverse-engineer their way through consumer interfaces, but a proper API—with usage instructions exposed via something like MCP and a strong auth layer—would make that reliable.
Personal banking choices have always rested on security, fees, and service. Forward-looking users may now add API availability to that list, betting that agent-mediated access becomes standard even if they aren't ready to hand over credentials today.
From novelty to norm
Apply the same logic to any service you touch in a week:
- Online marketplaces: Have an agent schedule the usual grocery order for the first morning slot.
- Office co-working: Book a desk at a specific location for the day.
- Ski resorts: Buy a day pass, load it to the resort card, and confirm the price first.
- Restaurants: Place a standing lunch order at the usual spot.
Where wouldn't you want one? The direction of travel is clear: user demand to interact with services through language-driven agents will grow, and any service facing competition will need an API to stay relevant. The standardization people once wished for on the web—a uniform way to interact with any product—may arrive not through a protocol like Gopher but through natural language at a terminal, powered by APIs underneath.
Agents, not apps
This second wave of APIs differs from the first in a crucial way. The initial push was for inter-service communication, scraping data, or building third-party apps on top of a platform. The new model is about fulfilling requests directly on behalf of an individual user, replicating what they would do through a first-party app, but programmatically.
That difference changes the incentives favorably for API adoption:
- APIs no longer enable products that could displace the platform—they enable an alternative route into the platform itself.
- Security gets easier because it can mirror the permissions and visibility of the product's own interface, nothing more.
- Since access patterns are single-user, platforms can impose stronger rate limits without hurting the intended experience, keeping costs and abuse manageable.
The goal is leeway, not unlimited access. An agent should be able to poll your LinkedIn for people you may know and send connection requests on your behalf. A scraping bot that tries to harvest the entire social graph should be throttled into a permanent ban. Slack's published rate limits show the shape of this balance: dozens of channel reads per minute are enough for a person, way too few for a multi-user application.
Where APIs won't come
Not every corner of the web will open up. Ad-supported platforms like Instagram and TikTok have little to gain from giving agents a direct line. Monopolies facing real competitive pressure have even less reason to change—you will not be paying your Xfinity bill through a bot anytime soon.
Early signs
Some companies are already racing ahead. Basecamp announced a new API, CLI, and bundled skill to make its product agent-accessible. Salesforce's "Headless 360" initiative promises that every Salesforce feature can be driven by API, MCP, or command line.
An API spring
The original API maximalists believed APIs would eat the world, enabling an explosion of interoperability that expanded user capabilities and changed things for the better. What followed was closer to an API winter—revenue, privacy, and abuse concerns kept interfaces closed.
That winter is ending. The agentic use case gives platforms a business reason to open up without giving away the store. As more people expect to command software in plain language, expect API availability to become a competitive edge and the proliferation of well-designed APIs to begin in earnest.
