Twitter Rate Limit Exceeded: Causes and Fixes (2026)

By Sorsa Editorial

Updated July 11, 2026: current X API per-resource read prices and the 2 million post-read cap verified against X's pricing documentation, plus the widely reported 2026 in-app reading caps for free and Premium accounts.

The word "rate limit exceeded" points at two completely different problems, and the fix depends on which one you have. If the message appeared while you were scrolling or refreshing the app, you hit a platform-level cap on your account. If it showed up in a script or server log as an HTTP 429, you hit the X API's per-endpoint rate limit. This guide covers both, starting with how to tell them apart.

For developers, the reason the same 429 keeps appearing is often that three separate limits all return it: the per-endpoint 15-minute window, your X account's own caps, and a monthly usage ceiling. We run Sorsa API, an alternative Twitter/X API, so we hit these limits and the 429s they produce every day, both in our own pipelines and across the read-heavy migrations we handle. That is also why we built Sorsa without the window model: one flat limit of 20 requests per second on every endpoint, no 15-minute resets and no per-app versus per-user split to juggle, with reads that run far cheaper than the official per-resource pricing. The numbers below are what you are working with on X right now, and further down we put the two models side by side.

Last verified: July 11, 2026, against X's rate-limit and pricing documentation.

Rate limit exceeded: the in-app message vs the API 429

The same three words describe two unrelated failures. One is a platform block on a normal X account, shown in the app or on the website. The other is an HTTP 429 returned to a program calling the X API. They have different causes, different reset behavior, and different fixes, so the first step is matching your symptom to the right column.

If you are a regular user and never touch the developer API, only the first two rows apply to you, and the fix is almost always to stop and wait. If you are building against the API, the 429 is a signal you can read and respond to in code, which is where most of this guide focuses. The two systems are enforced separately: a normal account and a developer app draw from different budgets, so being fine in one does not protect you in the other.

Blocked while browsing X: causes and how long it lasts

If the message appeared while you were using X normally, you crossed a platform-level cap tied to your account, not an API limit. X applies these caps to reading, posting, following, liking, and messaging to slow automation and protect its infrastructure. The block is temporary and clears on its own once the window resets.

The most common trigger for regular users is the daily reading cap introduced in July 2023 and still active, in relaxed form, in 2026. X does not officially publish the exact numbers, but the figures reported consistently across account testing are roughly 1,000 posts per day for unverified free accounts, around 10,000 for verified Premium accounts, and about 500 for brand-new unverified accounts under a month old. Every post that scrolls past counts as a read, even ones you do not tap, so heavy scrolling through a media-rich feed is what usually trips it.

Other account actions have their own caps. Following and unfollowing too quickly (roughly a few dozen per hour is where problems start), rapid-fire liking, sending many direct messages, or changing your account email more than a handful of times an hour can each produce the same message. Third-party apps connected to your account make API calls in the background and draw from your budget too, so a scheduler, an analytics tool, and a follower tracker running at once can drain it without any action from you.

How long it lasts depends on which cap you hit:

• Most window-based blocks clear in 15 to 60 minutes once the rolling window passes.
• Daily caps, including the reading limit, reset at midnight UTC.
• Repeated violations can extend restrictions to 24 to 72 hours on flagged accounts.

The fixes are simple and mostly about waiting cleanly. Stop refreshing, because every retry can extend the cooldown. Close the app or tab and step away for half an hour. If you use third-party clients, log out of all of them, since their background calls may be the real cause. Check Downdetector or X's own status updates in case a platform-wide incident is being misreported as a rate limit. If the block persists for hours, logging out, clearing cookies, and logging back in sometimes helps. For the full breakdown of account-level caps by action and account type, our reference on X account and API rate limits lists each one with current numbers.

The Twitter/X API 429: HTTP status and error code 88

On the developer API, "rate limit exceeded" arrives as an HTTP 429 response. It means you sent more requests to an endpoint than its limit allows inside the current window, so the next call is rejected until the window resets. The 429 is the transport-layer signal; X also returns an application-layer identifier in the response body.

The exact shape depends on which client and API version you are calling, but these all describe the same event:

• Plain status line: HTTP 429 Too Many Requests.
• X v1.1-style body: {"errors":[{"code":88,"message":"Rate limit exceeded"}]}, where code 88 is X's canonical identifier for this error.
• X v2-style body: {"title":"Too Many Requests","detail":"Too Many Requests","type":"about:blank","status":429}.
• Tweepy: raises tweepy.errors.TooManyRequests, which a generic exception handler around your calls will catch.
• Behind your own app: the front end often replaces the raw 429 with a generic "cannot load" message, so the real error only shows in your server logs.

Once you have confirmed a 429 status or code 88, the packaging does not matter and the same fixes apply. What does matter is figuring out which limit you actually crossed, because on the current X API three different limits can each return a 429, and the fix is different for each. If the error fires specifically during a login flow rather than during reads, it may not be a rate limit at all but an anti-automation check; we cover that separately in our guide to the "this request looks like it might be automated" message.

Which limit did you hit? The three layers behind a 429

A single 429 on the X API can come from three separate systems, and "I'm nowhere near my rate limit" is such a common complaint because people check one layer and miss the other two. Reading the response headers tells you which one stopped you.

Layer 1: the per-endpoint rate limit. Every X API v2 endpoint has its own cap on a rolling 15-minute window (a few use 24-hour windows), tracked in two independent pools: a per-app limit for Bearer Token auth and a per-user limit for OAuth user tokens. Recent search, for example, allows 300 requests per 15 minutes per user. Ten thousand users hitting an app-only backend all spend from one shared per-app pool, so an app can be throttled even when no single user is over their personal limit. This is the layer the x-rate-limit-* headers describe.

Layer 2: your X account's own caps. Separate from developer API limits, the X account behind your app is bound by platform-wide caps that count actions from web, mobile, and API together. An automation posting through the API draws from the same daily budget as manual posts from a phone. If your workflow acts on an account rather than only reading public data, an account cap can produce a 429 while your per-endpoint budget still shows room.

Layer 3: the monthly usage cap. Since X moved to pay-per-use pricing in 2026, standard accounts carry a hard ceiling of 2 million post reads per month. You can sit comfortably inside every 15-minute window and still get blocked because the monthly cap is spent. Rate limits control how fast you call; the usage cap controls how much you consume per billing cycle. They are tracked and enforced separately.

Here is how to tell them apart in a few seconds:

For read-heavy work, the monthly cap is usually what you hit first, not the rate limit. The per-endpoint window becomes the real bottleneck mainly for writes and for high-concurrency pipelines on app-only auth. The full per-endpoint numbers, pool by pool, live in our X API rate-limit reference, and the cost side of the 2 million cap is in our X API pricing breakdown.

The immediate fix: read the reset header and back off

The fastest way out of a Layer 1 rate limit is to wait exactly as long as the window needs, not a blind fixed interval. Every X API response, including the 429 itself, carries three headers that tell you where you stand:

x-rate-limit-limit: 900
x-rate-limit-remaining: 12
x-rate-limit-reset: 1783779300

x-rate-limit-limit is the ceiling for the current window. x-rate-limit-remaining is what you have left. x-rate-limit-reset is a Unix timestamp for when the window reopens. Subtract the current time from that timestamp and you know precisely how many seconds to wait. There is no guessing involved.

The naive recovery sleeps a flat 15 minutes and retries. It works but wastes time. A better pattern reads the reset timestamp, waits only that long, and falls back to exponential backoff if the header is missing:

import time
import requests

def request_with_backoff(url, headers, params=None, max_retries=5):
    delay = 1
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers, params=params, timeout=30)
        if response.status_code != 429:
            response.raise_for_status()
            return response

        reset = response.headers.get("x-rate-limit-reset")
        if reset:
            wait = max(int(reset) - int(time.time()), 1)
        else:
            wait = delay          # no header: exponential backoff
            delay *= 2
        print(f"429 hit, waiting {wait}s (attempt {attempt + 1}/{max_retries})")
        time.sleep(wait + 1)      # small buffer past the reset

    raise RuntimeError("Rate limit retries exhausted")

Two rules matter more than the code. Do not retry instantly, because a tight retry loop burns your remaining budget across other endpoints (on app-only auth) and can trigger heavier throttling. And do not ignore 429s in bulk pipelines: one 429 in a collection loop can mean hundreds of failed requests before your code reacts, so check x-rate-limit-remaining before each call and pause when it drops below roughly 10 to 20 percent of the limit. A time-series log of x-rate-limit-remaining is the single most useful artifact when you are debugging which call pattern drains the budget.

How to avoid Twitter API rate limits

Backoff gets you through the current window. Staying out of the wall is about spending fewer requests per unit of data. These are the moves that actually change the math, drawn from the read-pipeline migrations our team handles.

Batch instead of looping single lookups. X's batch tweet endpoint takes up to 100 tweet IDs in one call, and its user endpoint up to 100 usernames or IDs, each one request against a higher batch limit rather than 100 separate hits from a tighter one. Third-party APIs push this further: our bulk tweet endpoint takes 100 tweet URLs or IDs per request and our batch profile lookup takes 100 profiles, each counting as a single request from your quota.

Cache slow-moving data. Profile metadata, follower counts, and handle-to-ID resolutions change over days, not seconds. Cache them with a 12-to-24-hour TTL and skip the call on a cache hit. Engagement metrics move faster, so a 1-to-6-hour TTL is a reasonable balance for analytics.

Page with cursors, do not re-fetch. Use the response cursor to fetch the next page rather than re-running the original query. Re-running searches the same content you already paid for.

Swap polling for streaming where you can. Polling recent search every 30 seconds is 2,880 requests a day against one endpoint. X's filtered stream pushes matching posts over a single persistent connection instead. For providers without streaming, fast polling on a flat per-second limit covers most real-time needs; we go deeper on the tradeoffs in our guide to real-time Twitter monitoring.

Split across auth pools. Per-app and per-user limits are independent, so authenticating with both a Bearer Token and an OAuth user token gives you two buckets on endpoints that support both. This helps only server-side and is usually impossible in a client-only app.

The structural fix, if you keep hitting the wall on read-heavy work, is to move off the window model entirely. A flat rate limit removes the 15-minute reset and the per-app versus per-user split that cause most 429s in collection pipelines. Sorsa serves all 40 of its read endpoints at a flat 20 requests per second on every plan, and the limit can be raised for high-volume use cases through talk to sales.

Does a paid plan remove the rate limit?

No. On the official X API, upgrading raises the ceiling; it does not remove it. Every tier still throttles per endpoint, and Enterprise contracts (historically from around $42,000 per month) negotiate higher windows and lifted usage caps rather than an unlimited path. There is no self-serve plan that removes rate limiting on X.

Two structural routes exist if you keep hitting the wall on reads. One is to pay X more for a higher ceiling, which still leaves you inside the window model and the 2 million post-read monthly cap. The other is to read public X data through a third-party API that is not built on fixed windows, so cost scales with what you pull instead of a hard reset cliff. For a full field comparison, see our rundown of Twitter API alternatives.

For read workloads specifically, the two models line up like this:

One Sorsa request returns up to 100 tweets or up to 200 profiles, which is where the per-1,000 figures come from. On read-heavy collection that works out to up to 50x cheaper per read than the official per-resource pricing, and the 15-minute windows disappear entirely. The honest tradeoff is that Sorsa is read-only: anything that posts, sends DMs, or likes still runs on the official API, because that is the compliant path for writes. The common pattern we see is to keep writes on X and move the heavy reading to a flat-rate provider, which our migration guide walks through.

Other third-party APIs remove X's window cap too, but most are metered pay-per-use rather than flat. TwitterAPI.io, for instance, charges roughly $0.15 per 1,000 tweets and about $0.18 per 1,000 profiles (checked July 2026). Metered pricing kills the fixed-window 429, yet the bill still scales with volume and is not fixed ahead of time. Sorsa's flat plans keep the monthly cost predictable and land cheaper per read, from $0.02 per 1,000 tweets on batch endpoints.

In practice: a social-listening team that kept stalling on 429s

A mid-sized social-listening tool (roughly a dozen engineers) came to us after their X collection kept stalling mid-run. They were polling recent search on a tight loop to catch brand mentions for their own customers, then fanning out to per-author profile lookups, and could not work out why a "300 per 15 minutes" limit kept producing 429s. The cause was the usual one: app-only auth meant every search and every profile lookup drew from the same per-app pool, and the polling cadence alone was spending most of it before the fan-out even started.

We did not move them off the official API for anything they wrote; we moved the read-heavy collection to a flat-rate model and switched polling to event-driven collection. On per-resource pricing, that read volume sat in the awkward zone between cheap pay-per-use and a $42,000 Enterprise contract. Their read bill dropped by more than 90 percent, and the 429s disappeared once the 15-minute windows and the per-app versus per-user split were out of the picture. The kind of continuous brand-mention tracking they run is exactly what our social listening solution is built for.

FAQ

Why does Twitter say "rate limit exceeded"?

Twitter/X shows "rate limit exceeded" when you make more requests than a cap allows inside a set time window, so it blocks the action until the window resets. For regular users the trigger is usually reading, scrolling, following, or liking too fast. For developers it is an HTTP 429 from the API, where an endpoint's per-window limit, an account cap, or the monthly usage ceiling was crossed.

How long does a Twitter rate limit last?

Most Twitter/X rate limits are short. In-app blocks from scrolling or fast actions typically clear in 15 to 60 minutes once the rolling window passes, and daily caps reset at midnight UTC. On the API, the exact reset time is in the x-rate-limit-reset response header as a Unix timestamp, usually 15 minutes out. Repeated violations on an account can extend restrictions to 24 to 72 hours.

How do you avoid Twitter API rate limits?

Spend fewer requests per unit of data. Use batch endpoints that return up to 100 items in one call instead of looping single lookups, cache slow-moving data like profiles for hours, page with cursors rather than re-running queries, and prefer streaming or fast polling over tight poll loops. The structural fix for read-heavy work is a flat per-second rate limit instead of X's 15-minute windows.

Does a paid plan remove the Twitter rate limit?

No. Upgrading an official X API plan raises the ceiling but never removes rate limiting, and every tier including Enterprise still throttles per endpoint under a 2 million post-read monthly cap. A read-only alternative like Sorsa API replaces the window model with a flat 20 requests per second on every plan, from $0.02 per 1,000 tweets on batch endpoints, which removes the 429 rather than raising it.

Is the X API rate limit per user or per app?

Both, depending on the endpoint and your authentication. Bearer Token auth uses per-app limits, where every request from your application shares one pool, so an app can be throttled even when no single user is over their limit. OAuth user-token auth uses per-user limits, where each authenticated user gets an independent bucket. Many endpoints publish both figures.

Why am I rate limited when I have barely made any requests?

Usually one of three things. The cap is per-app as well as per-user, so your users collectively are over the app-wide limit. Or the endpoint you called has a tighter limit than you expect, so check that specific number rather than a headline figure. Or a background process, a forgotten script, or your monthly usage cap is the real cause. Logging x-rate-limit-remaining on every call makes it visible.

Getting started

If the 429s and the 15-minute windows above are the problem you are trying to get out of, the quickest way to feel the difference is to run a few calls yourself. Our interactive playground executes live endpoints in the browser with no key and no signup, so you can check the response shape before committing to anything. When you are ready to build, the Sorsa API quickstart authenticates you with a single API key in a header, and every new account starts with 100 free requests: one-time, no credit card, never expiring, and valid on all 40 endpoints, enough for up to 10,000 tweets or 20,000 profiles through the batch endpoints. Past that, pricing runs from $0.02 per 1,000 tweets on batch endpoints, with plans from $49 a month at the flat 20 requests per second. No app review, no OAuth handshake, and no rate-limit tables to keep in your head.

Reviewed by Keksich, founder of Sorsa, marketer and X API researcher.

How this guide was put together: the 429 format, the x-rate-limit-* headers, and the per-endpoint window behavior were verified against X's official rate-limit documentation, and the in-app reading caps against X's published limits guidance and current account testing, all on July 11, 2026, because these numbers shift without much notice. The three-layer diagnostic, the reset-aware recovery code, and the throughput framing come from our own work operating an alternative Twitter/X API and the read-pipeline migrations our team handles, including the anonymized social-listening case above (details merged and stripped of anything identifying). Pricing and usage-cap figures are summarized from our separate X API pricing coverage; competitor prices were checked at the source in July 2026. For who we are and how to reach us, see About Sorsa. No statistics, sources, or client outcomes here are invented.