The C&D Epidemic: Why Renting Platform Access Is a Business Liability

Why is renting platform access a business liability?

Renting platform access is a business liability because of platform risk from third-party APIs: the risk that a company you don't control can cut off, reprice, or sue your access to the data or infrastructure your product depends on, with no notice and no appeal. X Corp just did exactly that to Nitter and XCancel, two tools millions of people used to read X posts without an account, by sending cease-and-desist letters that took both offline within hours.

What actually happened?

On August 24, 2026, X Corp sent cease-and-desist letters to Nitter, the open-source project behind privacy-friendly X front ends, and gave it until 5 p.m. EST the next day to shut down. Nitter's creator, who goes by Zedeus, complied. The project's site now reads a message thanking contributors for seven years of work and stating that development has stopped while he seeks legal advice. XCancel, the most popular Nitter instance and effectively the last one still functioning after years of attrition, went dark the same day.

X's lawyers accused Nitter of "unlawful use and circumvention" of its API and of scraping data and accessing session tokens without authorization, citing the Texas Harmful Access by Computer Act and the Lanham Act. Whether or not the legal theory holds up, the letter did what it was designed to do. The service is gone.

This is not Nitter's first brush with death. In January 2024, X shut off the guest-account feature that let Nitter instances fetch public posts without logging in, killing the flagship nitter.net instance for a year before the project found a workaround. The 2026 cease-and-desist was the second kill shot, and this time it came from lawyers instead of engineers.

Is this a pattern rather than an incident?

Nitter is the third major case in four years of a platform holder using pricing or legal power to eliminate the ecosystem built on top of it.

In February 2023, X (then Twitter) ended free API access and introduced an Enterprise tier reported to start around $42,000 a month, a price that priced out nearly every third-party client, researcher, and hobbyist project running on the old free tier.

Four months later, Reddit followed the same playbook. It told Apollo developer Christian Selig that continuing to run his app at its existing usage would cost $12,000 per 50 million API calls, which worked out to roughly $20 million a year based on Apollo's traffic. For comparison, Selig said he paid Imgur, a site with a comparable user base, $166 for the same 50 million calls on its API. Apollo shut down on June 30, 2023, along with several other long-running third-party Reddit clients.

In each case the mechanism was different. Twitter used price. Reddit used price. X used a legal letter. The result was identical: a product with real users and, in Apollo's case, real revenue, was erased because it depended entirely on access it did not own.

The common thread

None of these products failed because the market rejected them. Apollo had users willing to pay a subscription. Nitter had a userbase big enough that X felt the need to kill it twice. The businesses died because the thing they were built on was never theirs. It was a revocable grant, dressed up as an API, and the grantor changed its mind.

Why does this matter beyond social media clients?

It is tempting to read this as a story about Twitter nostalgia and privacy tools. It isn't. Any company that builds a core workflow on a rented API, whether that's a data feed, a foundation model endpoint, or a platform's developer program, is exposed to the same three failure modes: the provider can reprice you out of viability, restrict the terms of use until your product breaks, or decide your use case is now a liability and send a letter that ends things in 24 hours. There is no tier of importance that protects you. Apollo had millions of users and still got a bill it could not pay. Nitter had run for seven years and still got a takedown notice with a same-day deadline.

The practical response is not "never use an API." It's treating any dependency on rented access as a liability on the balance sheet, not a feature. That means knowing exactly what breaks if the access disappears tomorrow, having a fallback that does not depend on the same provider, and being honest in a build-vs-buy conversation about how much of your product's value sits on infrastructure someone else can switch off. Companies that are quietly building their own agents and internal tools with AI are running into a version of this same question: does the workflow live on infrastructure you control, or on an account that a vendor can suspend. Remy's approach is built around treating employee-built software as owned infrastructure rather than a rented dependency, precisely because the Nitter pattern keeps repeating across every category of platform, not just social media.

For a deeper look at how to weigh that tradeoff internally, see Build vs. Buy in the Agent Era: Orchestrating Your Own Office of Clones. And for the cost side of the same argument, the economics of renting AI infrastructure versus owning it follow an identical logic to Apollo's API bill, laid out in The Hidden Costs of AI Agents: Why You Are Overpaying for Proprietary APIs.