X kills Nitter: your API integration is a permission, not a right

X Corp sent cease-and-desist letters to Nitter on August 24 and gave the project until 5 p.m. Eastern the next day to stop. Nitter.net is now offline and development has halted. If any part of your product reads data out of a platform you do not own, this is the lesson: your API integration is a permission someone else grants, and it can be revoked in twenty-four hours.

What actually happened

Nitter was an open-source front end that rendered public X posts without ads, JavaScript, or tracking cookies, and without an account. Per TechCrunch, X's letter accused the project of "unlawful use and circumvention of X's Application Programming Interface (API) and associated data," and cited the Texas Harmful Access by Computer Act and the Lanham Act among other laws. The deadline was 5:00 p.m. ET on August 25.

The developer, who goes by Zedeus, told TechCrunch that nitter.net is offline and development has stopped while he seeks legal advice, and that other instances received similar letters. Downstream sites that ran on Nitter — XCancel among them — went with it. X tried to break Nitter with technical restrictions back in 2024; that slowed the project but did not end it. Lawyers ended it in a day.

Why platform API risk matters for your business

The pattern that matters is not "X is litigious." It's that a dependency on someone else's data surface is a dependency with no SLA, no notice period, and no appeal. Nobody at Nitter got a deprecation window. They got a deadline.

We see the small-business version of this constantly. A dashboard that scrapes a supplier's portal because the supplier has no API. A lead router that pulls from a social platform's public pages. A pricing tool that reads a marketplace's listings. Each one works great until the counterparty decides it doesn't like the traffic, and then a system your operations depend on goes dark on a Tuesday afternoon.

The fix is not paranoia, it's inventory and isolation. Write down every external surface your systems read, whether the access is contractual or merely tolerated, and what breaks if it stops today. Tolerated access — no signed terms, no paid tier, just a URL that happens to respond — is the category to worry about. Then put a seam between that access and your business logic: one adapter module, one place to swap, so losing a source is a swap and not a rewrite. Cache what you are allowed to cache, so a hard cutoff degrades into stale data instead of a blank screen.

And where a paid, contracted API exists, pay for it. The invoice is the difference between a deprecation notice and a cease-and-desist.

Sources: TechCrunch, Nitter on GitHub.