# Building on X's Enterprise API

> Why TweetSweep deletes through X’s official paid API rather than browser automation: revocable access, no password, and the rate limits that come with it.

- Source: https://tweetsweep.com/blog/tweetdeleter-becomes-official-x-com-twitter-enterprise-partner-empowering-users-x-post-tweet-deletion-capabilities
- Published: 2023-10-10
- Updated: 2026-08-16
- Reading time: 6 min

---
## Why the official API matters

Most obvious to me are tools that automate a logged in browser session, so work against the platform not with it. They break whenever X changes its markup, they put your account at risk of being flagged for automated behaviour and almost always require your password instead of a revocable authorisation. And since TweetSweep uses the official API, your X credentials never touches our servers. Authentication occurs via OAuth, this is the same standard used by every major web service. You award a certain permission at Settings, Security and account access then Apps and sessions. When anybody can only be in the position so long as it is scoped to what deletion needs and they also have this permission, you see clearly who has that permission — not all users have every power anymore — and I can revoke mine at any time without changing my password. No password ever changes hands.

The moment a browser-automation tool fails to work, you would notice the tangible difference. X changes its UI a few times every year, so if you depend on some DOM selectors or CSS classes to identify the elements in the X interface, your script will fail silently until the developer pushes a patch. Since API endpoints change infrequently and deprecations are announced months in advance, even if you relied on a private interface of an SDK breaking your tests, it would not go unnoticed. However, when TweetSweep fails to operate its due to X having changed the API contract and not because a button moved. And that stability allows you to create and schedule a deletion job and walk away, rather than having to check back in on whether the tool still runs.

## What the API charges

In 2023, X shifted to a pay-per-use pricing model. Each API call has a fixed credit cost, and deletion is charged based on each request. If reading a single post costs one dollar — deleting a single post will cost the same. That cost is very real, and it is the reason why serious bulk deletion does not come free. TweetSweep fills whole of the margin by passing through X's rate unchanged and taking a single flat fee on top. The amount is listed upfront (before you order) so you can see how much the job cost before any posts are taken down.

The per-request cost also explains why — as a product with normal server costs — it prefers an uploaded archive to a live timeline scan. The archive file you already own have access to all of your posts, including those beyond the 3,200-post limit. It doesn't cost either side anything to load that archive. That is to say that scanning the live timeline looking for posts you need to delete costs one API call per post read and that cost is exactly the same whether you want to keep the post or delete it. There's no cost for using your uploaded archive, and is therefore the reason why exporting and uploading is not a feature quirk but an intentional optimised solution

## What the rules require

Being within the API also means being defined by its constraints. X limits users to 50 delete requests every 15 minutes. That's not a decision any developer gets to make. TweetSweep operates within that ceiling and queues deletions appropriately. Deleting 1,000 posts will take around five hours from first deletion to last Deleting 50,000 posts will happen over a couple of days. They are slower than what browser automation is capable, but will not trigger X's automated abuse detection.

The second constraint is the ceiling of timelines. The test account should not return more than roughly 3,200 posts from any user's timeline through X's API. There may be posts that you have just not published, and a ceiling is still there. Assuming you have 10,000 posts the recently updated live timeline scan will only see 3,200 in total. Older than that is hidden from you in the API, unless you put your archive file. TweetSweep does not exceed the threshold set by these. If your scan ends at 3200, it reminds you and asks you to upload your archive. Bypassing an upper limit is just a lot more difficult, and so a tool that merely works within it is far more likely to complete at all.

## What the archive solves

Your X archive can be everything you have ever posted, deceased or otherwise beyond the 3,200-post ceiling. You can download it in less than a minute here: Settings, Your account, Download an archive of your data. TweetSweep takes the zip file directly and reads all posts within. js file. The only data that ever leaves the processing pipeline is the deletion requests themselves. We parse the archive on our servers and throw it away after we run the job. No copy is stored.

The archive also means you can mass delete posts from any time period, not just the last few thousand. If you keep wanting to get rid of posts between 2010 and 2015, those archives are packed with them. The live timeline cannot touch them. The archive contains also reply tweets, retweets with your own text, and quote tweets that LIVE scan misses due to API pagination quirk. So if the result is more complete, not just a partial deletion you do not have to pay a penny in extra fees for that completeness; because reading from the archive comes at no cost.

## What the rate limit translates to for speed

It takes one API call per deletion. This means that 200 deletions podem ser feitas por horas a uma velocidade máxima de 50 chamadas a cada 15 minutos. That rate is fixed. TweetSweep does not use batching requests or go around the limit. Each delete is individually approved by your access token and billed to X. The interface contains a queue, as well as a live calendar of how many requests you have left and when the next window starts/ends. The job resumes from where the job stopped if you close the page and come back later.

For most users, this speed works just fine. Removing hundreds of post goes back to a few hrs. It takes about 2 days of non-stop work to delete 10,000 posts. This runs the queued in background and sends a notification when its done. TweetSweep does not hang your browser or require your machine to be online. Rate limit is the slowest step in this whole process, and it also prevents your account getting flagged for suspicious activity. Come to think of it, a quick delete that suspends your account is not the real deletion.

## What the fee covers

The single flat fee pays for two things, the API calls X fees and set-up (the infrastructure needed to process your archive and support queue). Your fee pays for every API credit your deletion consumes. TweetSweep is funded by you filling your wallet to help others delete their tweets. The margin is relatively low and clear. The interface shows only the fee before you confirm the job, and additional charges for retries or extensions do not appear anywhere later.

The cost is less if you upload any archive because with it there are no livescan costs. A live scan costs more — because reading every post in a batch has the same cost as deleting it. The interface has both the options on either side along with its prices. You choose which one to use. It also include the cost of automatic recovery, that is when a post need to be retried in case of an API failure. Retries happen automatically and are free of charge. What happens after you can confirm on the job is included in the fee you have paid already.
