Platform Rot: When the APIs That Built the Internet Start to Crumble

There is a particular kind of grief that software developers rarely discuss publicly. It is not the grief of a failed product launch or a rejected pull request. It is the grief that arrives in an email—usually terse, sometimes apologetic—announcing that an API you built your livelihood around will stop working in ninety days.

Over the past several years, that email has arrived in the inboxes of thousands of developers across the United States and beyond. The senders have included some of the most powerful technology companies in the world. The consequences have ranged from inconvenient to catastrophic, and the pattern has forced a long-overdue reckoning with what it actually means to build on someone else's platform.

The Infrastructure That Was Never Really Yours

The modern web was constructed, in substantial part, through a philosophy of openness. When Twitter launched its API in 2006, it was not merely a technical offering—it was an invitation. Developers responded enthusiastically, building scheduling tools, analytics dashboards, archiving utilities, and accessibility clients. Many of those applications became indispensable to the very users Twitter was trying to retain. The platform and its ecosystem appeared to be in a symbiotic relationship.

Reddit operated under a similar implicit agreement. Its API powered an enormous range of third-party applications, most notably Apollo for iOS, which had accumulated millions of users who preferred it to Reddit's own client. These applications filled genuine gaps, often serving users with disabilities or users in bandwidth-constrained environments who found the official app unusable.

What both platforms shared—and what neither communicated clearly to the developers who built on them—was that the API was always a conditional gift. The terms of the gift could change at any time, for any reason, at the sole discretion of the platform.

The Unraveling

The sequence of events that began in 2023 illustrated this dynamic with unusual clarity. Twitter, rebranded to X under new ownership, moved swiftly to eliminate free API access and restructure paid tiers at prices that rendered most independent developer projects economically nonviable overnight. The result was the rapid shutdown of dozens of tools that had served researchers, journalists, and ordinary users for years. Academic projects studying misinformation and public health communication lost access to data they had spent years collecting methodologies around.

Reddit's API repricing followed a similar arc, though it unfolded more publicly and contentiously. When the company announced it would begin charging for API access at rates that Apollo's developer, Christian Selig, calculated would cost his application approximately $20 million per year, the response from the developer community was swift. Apollo shut down. So did several other beloved third-party clients. A coordinated subreddit blackout, one of the largest collective actions in the platform's history, demonstrated the depth of user frustration—but did not change the outcome.

These are only the most visible examples. Google has quietly deprecated dozens of APIs over the years, including the Google+ API, the URL Shortener API, and various Maps endpoints that had become load-bearing components in thousands of small business websites. Facebook's platform changes after the Cambridge Analytica scandal dramatically restricted what third-party developers could access, eliminating entire categories of social applications that had existed for years.

The Economics of Betrayal

From a purely financial standpoint, the calculus that platforms perform when deprecating APIs is straightforward. Third-party developers extract value from the platform's data and user base. If that value is not flowing back to the platform in a measurable way—through advertising revenue, subscription conversions, or data licensing—then the API represents a cost center rather than a growth driver.

What this accounting framework omits is the role that third-party ecosystems play in building and sustaining platform value in the first place. The developers who built tools on Twitter's API also built habits. They created workflows that made Twitter indispensable to journalists, researchers, and power users. When those tools disappear, the habits often do too.

Developers who spoke with WikiPF described a consistent experience: years of building in good faith, followed by a sudden and often poorly communicated change that rendered their work obsolete. Several noted that the deprecation notices they received offered timelines too short to meaningfully pivot a product, let alone a business.

"You build something that fills a real need," one independent developer told us, "and for a while it feels like the platform wants you there. Then you realize you were never a partner. You were just using their infrastructure until it was inconvenient for them."

The Implicit Social Contract

At the core of the API deprecation crisis is a question about what obligations, if any, technology platforms owe to the developers who build on them. There is no legal framework that compels a company to maintain an API indefinitely. Terms of service almost universally reserve the right to modify or discontinue services at will.

But the law and the social contract are different instruments. When a platform publishes documentation, hosts developer conferences, issues SDK updates, and publicly celebrates the applications built on its infrastructure, it is doing more than offering a technical resource. It is making an implicit promise that the ecosystem it is cultivating has a future.

The developers who accepted that promise—many of whom declined venture capital, built small sustainable businesses, and invested years in a single platform relationship—now find themselves in a difficult position. The promise was never written down. And that, many argue, is precisely the problem.

What a More Durable Architecture Looks Like

The deprecation wave has accelerated interest in architectural approaches that do not depend on the continued goodwill of a single platform. Federated and decentralized protocols, such as ActivityPub—the standard underlying Mastodon and other Fediverse applications—offer one model. Because no single entity controls the protocol, no single entity can deprecate it.

Other developers have moved toward local-first architectures that treat cloud platform access as optional rather than essential. Some have begun advocating for API stability commitments as a standard clause in developer agreements, similar to the deprecation policies that operating system vendors maintain for their platform APIs.

None of these approaches fully resolves the tension between a platform's right to evolve and a developer's need for stability. But they represent a growing recognition that the current model—in which platforms hold all the leverage and developers absorb all the risk—is not a sustainable foundation for innovation.

Documentation as Accountability

For a knowledge base like WikiPF, the API deprecation crisis carries a specific significance. Much of the documentation that exists on the web about building with major platform APIs was written during periods of relative openness and stability. That documentation now exists as a historical record of infrastructure that no longer functions as described—a digital archaeology of broken integrations and obsolete endpoints.

Preserving that record matters. Understanding why platforms deprecate APIs, what the consequences have been, and what alternatives developers have pursued is not merely a technical exercise. It is a form of institutional memory for an industry that has historically been poor at learning from its own patterns.

The great API deprecation is not a crisis that ends with a single policy change or a regulatory intervention. It is a structural feature of an ecosystem built on asymmetric relationships. Documenting it clearly is the first step toward building something more durable.