Twitter Rate Limit Exceeded
What triggers the limit, how long it lasts, and why it hits API tools and heavy scrolling in different ways.
Error definition
Rate limit exceeded OneRemarkableSectionWhat it means – You requested more from X than what it will serve during this time frame. Its not a ban, an account lock or a software bug. The window resets itself, typically within 15 minutes and sometimes up to an hour. The only consistent answer is to refrain from requesting whilst her window is open. You should see the message in a banner on the home timeline or as a failed load when you open a profile. Do not touch the app for some time.
X has also recently started limiting how many recommendations and posts an account can read per day - those daily caps have changed a few times since. The limit in the app is different than the API limit that tools hit. Every action, whether scrolling the For You tab or pulling to refresh, deducts from the read quota. Reaching the ceiling during a session stops any new content until the next reset. Old Verified Accounts ** Backlogged: Older accounts are higher than newer or unverified. Scroll habits that work on an account from two years ago break in a login from one year ago.
App usage triggers
Multiple scrolling, refreshing fast, opening lots of profiles in a short time or running multiple app sessions of the same account will flag the in-app limit. For example the home timeline, search and notifications call separately. You can trigger the banner on a lower-tier account simply by opening ten profiles in one minute. It is not like the client warns you when your number comes closer. It simply stops loading. The block actually extends if you continue pulling to refresh after the banner displays since those retries will fall in the same daily window.
The mobile app uses the same daily read pool for your account as the web client. If you have already used the quota using the iPhone app, switching to x.com in a browser does not give you a new quota. If you remain signed-in to third-party clients they also tap that well without you looking at them. One phone sitting idly on the first can be pushed over by a background refresh of the second. Consider all surfaces signed in, to be a single bucket. Always log out of any unused devices before you begin an extended scroll.
Connected apps and sessions
Do not be signed in with the same account on many devices at once. All of your still active sessions will keep polling as long as the browser is open for new posts and notifications. Remove third-party applications that you do not use. Open Settings → Security and account access → Apps and sessions. Cancel any that you don't recognize or no longer need. These apps run in the background using up your allowance even if you haven — for months. It could even be the hanging old analytics tool that makes it appear after some minutes of normal usage.
Accounts that have lesser (or no) history score lower than more established ones. A newly created account with no checkmark from last month will get wall after far fewer profile views than an old verified login from years ago. They change, and X does not publish the exact numbers. The only way to find your ceiling is by banging your head against it. You are designed to read your subscriptions, if you just opened an account subscription and do not enter the price by day sessions 9. Don't run a cleanup tool and go on a heavy browsing session in the same hour with the same new account.
Deletion API caps
The limits of the API itself are stricter than the ones you experience in the app. Post deletion has a limit at 50 requests per user per 15 minutes. That is a hard cap any tool cannot negotiate their way around. You pay the same to delete a post as you would to read one. The truth is, any bulk deleter that says it can delete 10k posts instantly is lying. It will use up that 50-request window before you can say "boilerplate," and then just sit there. The stronger a tool is, the more it will always hydrate under the cap and queue the rest.
X's 3,200-post ceiling cuts off a full timeline sync. Content older than that cutoff never shows up in the initial pull, so a tool that only syncs at one point will miss those posts altogether. Well paying extra page requests each time you need to go a further back, and each of those pages also counts against the same 50-request bucket when you delete later. And that is the reason you can never delete a big past in one go. The math is simple. 200/hour, or 50 deletions every quarter hour. Everything over, trips the same rate error in the app.
Reset window steps
Wait. Close the app instead of being in a refresh loop, as retrying inside the window increases the problem. In the recents screen, force-quit the iOS app or Android app so it cannot poll in the background. Offline, close the tab and do not return to x.com for at least 15 minutes. If we add more traffic, and the clock rolls over to zero the reset is not instantaneous. Give it a full quiet period. When you first see the banner check the time and wait for 20 mins before trying again.
Do remember to only open one client after the monitored silence! Fetch home timeline one time and don't fetch it again No banner? You likely have the all-clear, If it is present, wait for 15 minutes more. Keep from opening TweetSweep or any other 3rd-party device till the in-app feed gains to serious situation. The first 50 slots on failures will be occupied by a deletion job which is started while the limit still applies. After you confirmed the account healthy on the official app then launch the tool. That sequence doesn't pile two traffic sources over a quota still rebuilding.
Queued deletion pacing
Clean-up with a real purpose is a problem about scheduling, not speed. TweetSweep has queues deletions and paces them per X's cap and methodically chips through a backlog rather than fail halfway through leaving you to guess what ultimately got erased/videos deleted. The tool adheres to the 50-requests limit and waits until a new window resets. You are not sitting there missing another retry. A run that would have died at post 51 instead trundles onto the next quarter hour, then the next, until the chosen range is void of entries. That is how a multi-year archive earns its own complete annihilation.
Clearing a considerable history is never instant but any honest tool will inform you of that before going on. If nothing else was taking a cut of the quota, pacing ten thousand posts at 200 deletions per hour takes around two days straight. TweetSweep will not obscure the 50-request limit or the first-sync wall of 3,200 posts. It you want delete the oldest one first you run the job over passes. Every 15-minute window does its 50, then it sleeps. Any service that promises an instant clean runs into the same rate limit exceeded banner we just did.