X (Twitter) API Rate Limits in 2026: Full Tables + Fixes

By Sorsa Editorial

Updated July 2026: rebuilt as a full reference covering every X API v2 endpoint category (roughly 100 endpoints, re-verified against X's official rate-limit tables at the end of July 2026). Adds media, bookmarks, Spaces, trends, streaming, and webhook limits, expands the free-tier section, and keeps the April 2026 Enterprise-only change and the May 2026 account-cap cut current.

There are actually three separate systems that can stop your requests, and they all return errors that look alike. Your developer app sits under the X API's per-endpoint rate limits. The X account it posts from sits under separate account-level caps, now as low as 50 posts a day for unverified accounts. And a pay-per-use balance sits under a monthly usage cap of 2 million post reads on top of both. Hitting any one of the three stops you cold, which is why "I'm nowhere near my rate limit" is such a common and confusing complaint.

This guide covers all three layers with current numbers, starting with the complete per-endpoint tables. 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 migrations we handle. That is also the reason we built Sorsa without them: one flat limit of 20 requests per second on every endpoint, no 15-minute windows and no per-app versus per-user split to juggle, and reads from $0.02 per 1,000 tweets on batch endpoints against $5.00 per 1,000 post reads on official pay-per-use, with 100 free requests on signup to test it. The numbers below are what you are working with on the official X API right now, and further down we put the two models side by side.

Last verified: July 31, 2026, against X's official rate-limit and account-limit documentation.

The limits people look up most

If you came here for one number, it is probably in this table. Everything is covered in full further down.

Table of Contents

• How X API rate limits work
• X API rate limit tables: every endpoint
• X API posting rate limits: API caps vs account caps
• X API free tier limits in 2026
• How many tweets can you actually pull per day?
• Standard vs Enterprise rate limits
• What happens when you hit a rate limit (429)
• How to stay under rate limits
• Frequently asked questions

How X API rate limits work

X API v2 rate limits are set per endpoint, with no single global number. Most endpoints reset on a 15-minute rolling window; some, such as posting and media upload, use 24-hour windows, and a few streaming and archive endpoints add a per-second cap. The window starts from your first request to that endpoint, not from a fixed clock time, so "300 per 15 minutes" means 300 requests in any rolling 15-minute span.

Per-app vs per-user limits

Every endpoint tracks up to two independent pools:

Per-app limits apply when you authenticate with a Bearer Token (app-only auth). Every request your application makes draws from one shared pool, no matter which of your users triggered it. Ten thousand users hitting your backend at once all spend from the same per-app bucket.

Per-user limits apply when you authenticate with OAuth 1.0a or OAuth 2.0 user tokens. Each authenticated user gets a separate bucket. With 100 users, each one has their own 300 recent-search requests per 15 minutes.

Some endpoints expose both pools, some only one. In the tables below, "n/a" means that auth type is not supported for that call.

Reading your limits from the response headers

Every X API response carries three headers that tell you exactly where you stand:

x-rate-limit-limit: 900
x-rate-limit-remaining: 847
x-rate-limit-reset: 1705420800

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 resets. Parse that timestamp, subtract the current time, and you know precisely how many seconds to wait. You never have to guess.

Rate limits vs usage caps vs account limits

This distinction trips up more developers than any single number, so here are all three layers side by side:

Since X moved to pay-per-use pricing in early 2026, every resource you fetch costs money, and standard accounts carry the hard 2-million-post-read monthly cap. You can sit comfortably inside your 15-minute rate limit and still get blocked because you burned through the monthly cap. For the cost side (per-action prices, the 24-hour deduplication window, and what changed on April 20, 2026), see our X API pricing breakdown.

One more disambiguation: if you are an ordinary X user seeing "rate limit exceeded" while scrolling or posting from the app, that is the platform-side cap, not the developer API. We cover that separately in what "rate limit exceeded" means on X and how to fix it. Everything below is for developers calling the API.

X API rate limit tables: every endpoint

X's official documentation currently lists roughly 100 endpoints across more than a dozen categories. The tables below cover all of them, grouped by what you are trying to do rather than by X's internal product taxonomy. All figures were read from X's official rate-limit tables and re-checked on July 31, 2026. Limits are per 15 minutes unless marked otherwise.

Search and tweet lookup rate limits

Search deserves the closer look because it splits into two endpoints with very different ceilings. Recent search gives 300 requests per 15 minutes per user but only reaches back 7 days, which covers most tweet searches run via the API. Full-archive search reaches to 2006 but caps you at 1 request per second, so you cannot burst. If you need historical depth, that 1/sec hard cap is the number to plan around; we cover working within it in our guide to pulling historical Twitter data.

Timeline and mention rate limits

Posting, deleting, and media rate limits

The two numbers that matter for most posting automations: 100 posts per 15 minutes per user, and 50 deletions per 15 minutes per user. Both are API-side ceilings; the account-level caps below usually bind first.

Engagement lookup rate limits (likes, retweets, quotes)

All engagement lookups sit at a uniform 75 per 15 minutes, one of the tightest read ceilings in the API. Auditing who retweeted or liked a viral post exhausts this fast.

Engagement write rate limits (Enterprise-only since April 2026)

Effective April 20, 2026, X removed following, likes, and quote-posts from all self-serve tiers. The limits above remain in X's tables, but they now apply only under an Enterprise contract. Posting and direct messages stay available on pay-per-use.

User lookup and follower rate limits

The followers and following endpoints share one 300-per-15-minutes limit on both pools. At 1,000 results per page, paginating a million-follower account takes 16 to 17 windows, roughly four hours of wall-clock time. If pulling followers and following lists at scale is your core workload, that pacing is the constraint to design around.

Direct message rate limits

At 15 reads per 15 minutes per user, DM-heavy workflows hit their ceiling almost immediately; the 24-hour send caps make automation here deliberately slow by design.

List rate limits

List tweets and list members at 900 per 15 minutes are among the most generous read limits in the API, which is why lists remain a popular monitoring workaround.

Spaces, trends, Communities, analytics, and news rate limits

Bookmarks, blocks, and mutes rate limits

Streaming and webhook rate limits

Streaming endpoints are app-only. The important mental model: the limit governs connection attempts and rule changes, not delivered volume, which is why a single healthy stream connection beats any polling loop.

Compliance and usage rate limits

X API posting rate limits: API caps vs account caps

X enforces posting on two separate layers in 2026, and the API layer is almost never the one that stops you.

The API write endpoint (/2/tweets) allows 100 posts per 15 minutes per user and 10,000 per 24 hours per app. Separately, the X account you post from is bound by account-level caps that apply across web, mobile, and API alike. In May 2026 that account cap dropped to 50 original posts and 200 replies per day for unverified accounts, down from a long-standing 2,400.

This is the trap. Developers read the API limit (100 per 15 minutes looks generous, nearly 9,600 a day per user), architect around it, and then the bot stops at 50 posts. The API limit was never the binding constraint:

• Unverified account + API automation: the account cap of 50 original posts per day hits long before the API window matters. Replies are capped separately at 200 per day, and reposts and quotes are widely reported to count toward the 50, though X has not stated so outright.
• Verified or Premium account + API automation: the account-level cap is higher (X does not publish the exact figure), so the API write limit becomes the real ceiling.
• App-level scale: even with many verified users, 10,000 posts per 24 hours per app is a hard wall for high-volume publishing.

X's account-limit documentation is explicit that these caps count actions from all devices, web, mobile, and API together, so your script and your phone share the same daily post budget. The most commonly automated account-level caps:

For the full account-side picture, including verified-tier ceilings, semi-hourly sub-intervals, and what changed in May 2026, see our dedicated guide to X posting limits and daily post caps.

Posting is also the one area no read-only alternative can help with. Providers like Sorsa are built for reading X data at scale, not writing to it, so if your job is auto-publishing, the official API write endpoints are unavoidable and these are the limits you live with.

X API free tier limits in 2026

There is no general free X API tier for new developers in 2026. The standalone free tier was discontinued when pay-per-use launched in February 2026, so new accounts must buy credits before making any call. The only surviving free access is a narrow, approval-gated program for designated public-utility apps.

For anyone still comparing against the legacy free tier, its rate limits were always severe by design:

• Write-only. Zero post-read access: no timelines, no search, no tweet lookup.
• 17 requests per 24 hours on the post endpoint, per app and per user combined, which works out to roughly 500 posts a month in practice, despite the "1,500 posts per month" figure X marketed.
• 24-hour windows instead of the friendlier 15-minute windows used on paid access.

In other words, the free tier never had usable rate limits for reading X data, and now it does not exist for new signups. The practical free path for testing reads today runs through third-party access: every new Sorsa account starts with 100 free requests, one-time, no card required, and they never expire. They cover all 40 endpoints at the same flat 20 requests per second as paid plans, which through the batch endpoints is enough for up to 10,000 tweets or 20,000 profiles before anyone pays for anything. For how official access and keys work now, see our walkthrough of getting an X API key in 2026.

How many tweets can you actually pull per day?

Rate-limit numbers on their own do not tell you much. What matters is throughput: how many tweets, profiles, or follower records you can realistically collect in a day. Here is the math for the most common scenarios, assuming per-user authentication.

Tweet search (recent)

• Rate limit: 300 requests / 15 minutes = 1,200/hour = 28,800/day
• Max results per request: 100
• Theoretical ceiling: 2,880,000 tweets/day

That sounds generous, but the pay-per-use billing cap is 2 million post reads per month. You would burn the entire monthly allowance in under a day of continuous searching. The rate limit is not your bottleneck here. The monthly cap is.

User timelines

• Rate limit: 900 requests / 15 minutes = 3,600/hour
• Results per request: ~20 (varies)
• Theoretical ceiling: ~72,000 tweets/hour per account

For collecting individual timelines, rate limits are rarely the constraint. The real limit is how many tweets the account has posted.

Followers

• Rate limit: 300 requests / 15 minutes = 1,200/hour
• Max results per page: 1,000
• Theoretical ceiling: 1,200,000 follower records/hour

X returns up to 1,000 followers per page, making this one of its higher-throughput read endpoints. For comparison, on Sorsa's flat-rate model the followers endpoint returns up to 200 profiles per request with no 15-minute window, just a flat 20 requests per second, which works out to roughly 4,000 profiles per second or about 14.4 million per hour. On very large follower graphs the difference compounds quickly.

The real bottleneck, summarized

For read-heavy work at any meaningful scale, the monthly billing cap is what you hit first, not the rate limit. Rate limits become the practical bottleneck mainly for writes, for engagement lookups at their tight 75-per-window ceiling, and for high-concurrency pipelines on app-only auth.

Standard vs Enterprise rate limits

Everything above describes standard (pay-per-use) rate limits. Enterprise is a different world. Enterprise customers negotiate custom limits directly with X's sales team, and the specifics are not public, but the general shape is known:

• Custom per-endpoint limits, typically far higher than standard
• Higher or lifted monthly usage caps (the 2 million post-read ceiling can go away)
• The engagement writes removed from self-serve in April 2026 (follows, likes, quote-posts)
• Full-archive search at higher concurrency, plus Activity API and webhook access with custom limits

The minimum Enterprise price has historically started around $42,000 per month, though this may have shifted with the pay-per-use transition. Approval is selective and onboarding can take weeks.

Who actually needs Enterprise?

Enterprise fits large SaaS platforms that resell X data to their own customers, financial firms running real-time models, and research groups processing millions of posts a month. If you need both more than 2 million post reads per month and write access, Enterprise is your only route on the official API.

For teams that need high throughput on read operations without the Enterprise price tag, this is exactly the gap third-party providers fill, and where we built Sorsa to sit. Our flat 20 requests per second applies on every plan, including the $49/month Starter, with no per-endpoint tables and no 15-minute windows to manage; the limit can be raised on request for high-volume use cases via talk to sales. The honest trade-off is that Sorsa is read-only: no posting, no DMs, no like or follow writes. If all you need is the absolute cheapest single read and you can tolerate piecing together reliability yourself, there are barer options; if you want dependable, complete read access at a flat price, that is the case we are built for. For a fuller field comparison, see our rundown of X API alternatives.

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

On Sorsa's batch endpoints that comes to from $0.02 per 1,000 tweets, and even on plain search pagination it stays around $0.10 per 1,000 on the Pro plan, against $5.00 per 1,000 post reads on official pay-per-use. For read-heavy collection, that works out to up to 50x cheaper per read, and the per-endpoint windows disappear entirely. The reason to stay on the official API is writes: anything that posts, sends DMs, or likes still has to run there, because Sorsa is read-only by design. The practical pattern we see most often is to keep writes on the official API and move the heavy reading to a flat-rate alternative; our migration guide covers doing that switch cleanly.

What happens when you hit a rate limit (429)

When you exceed a rate limit, X returns HTTP 429 with this body:

{
  "errors": [{
    "code": 88,
    "message": "Rate limit exceeded"
  }]
}

The response still includes the rate-limit headers, which is the part that matters. x-rate-limit-reset tells you exactly when the window reopens, so you never have to blindly sleep for a fixed interval.

A proper recovery strategy

The naive approach sleeps for a flat 15 minutes and retries. It works but wastes time. A better approach reads the reset timestamp and waits only as long as the window actually needs:

import time
import requests

def request_with_rate_limit_handling(url, headers, max_retries=3):
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers)

        if response.status_code != 429:
            return response

        reset_timestamp = int(response.headers.get("x-rate-limit-reset", 0))
        wait_seconds = max(reset_timestamp - int(time.time()), 1)
        print(f"Rate limited. Waiting {wait_seconds}s until window resets.")
        time.sleep(wait_seconds + 1)  # +1s buffer

    raise Exception("Rate limit retries exhausted")

A few things to watch for:

Do not retry instantly. A retry loop with no delay burns your remaining requests across other endpoints (on app-level auth) and can trigger more aggressive throttling.

Do not ignore 429s in bulk pipelines. In a tight collection loop, one 429 can mean hundreds of failed requests before your code notices. Check x-rate-limit-remaining before each request and pause when it drops below 10 to 20.

Log your remaining requests. When you are debugging rate-limit issues, a time-series log of x-rate-limit-remaining is the single most useful artifact. It shows exactly which call pattern is draining your budget.

Check which of the three layers you actually hit. A 429 with the rate-limit headers near zero is the endpoint window. A block that persists after the window resets is usually the monthly usage cap or an account-level cap, and no amount of backoff fixes those.

How to stay under rate limits

The standard advice ("cache responses" and "use exponential backoff") is not wrong, but it is incomplete. These are the moves that actually change the math, drawn from the pipeline migrations we have handled.

1. Use batch endpoints instead of individual lookups

The /2/tweets endpoint accepts up to 100 tweet IDs in one request: one request, one rate-limit hit, 100 tweets back. Making 100 individual /2/tweets/:id calls instead spends 100 hits from a tighter limit (450/15min versus 3,500/15min for batch). The same logic applies to /2/users, which takes up to 100 usernames or IDs.

Third-party APIs push batching 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. More tactics for cutting request volume are in our notes on optimizing API usage.

2. Use streaming instead of polling

Polling /2/tweets/search/recent every 30 seconds means 2,880 requests a day to that one endpoint. X's filtered stream pushes matching tweets to you in real time over a single persistent connection: one connection, up to 250 matching posts per second. The catch is 50 connection attempts per 15 minutes and only 1 active connection at a time, but for monitoring keywords or accounts it beats polling outright. We go deeper in our guide to real-time Twitter monitoring.

3. Cache user profiles aggressively

User profiles change slowly. Display names, bios, and follower counts move over days, not minutes. If your app fetches user data alongside tweets, cache profiles 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 usually right for analytics; real-time dashboards have no good substitute for fresh calls.

4. Monitor headers and throttle proactively

Do not wait for a 429 to slow down. Track x-rate-limit-remaining on every response and add a soft threshold: when it drops below roughly 10 percent of the limit, slow down before you hit the wall.

remaining = int(response.headers.get("x-rate-limit-remaining", 100))
if remaining < 30:   # soft threshold
    time.sleep(2)    # gentle slowdown before the hard stop

5. Distribute across authentication methods

Per-app and per-user limits are independent pools. If you authenticate with both a Bearer Token and an OAuth user token, you effectively get two buckets for endpoints that support both. Tweet lookup allows 3,500 per 15 minutes per app and 5,000 per 15 minutes per user, so using both nets 8,500 per 15 minutes. This only helps if your architecture supports dual auth paths; it is straightforward server-side and usually impossible in a client-only app.

One more tool worth knowing before you burn real quota: X ships a self-hosted API Playground (released December 2025) that emulates v2 endpoints locally, including rate-limit simulation, so you can test your backoff and header handling without spending a single live request.

In practice: a fintech analytics team that kept hitting 429s

A small fintech analytics team (around eight engineers) came to us after their X data pipeline kept stalling. They were polling recent search on a 30-second loop to catch market-moving posts, fanning out to per-author profile lookups, and could not understand why a "300 per 15 minutes" limit kept producing 429s mid-collection. The cause was the usual one: app-only auth meant every profile lookup and every search drew from the same per-app pool, and the polling cadence alone was spending most of it.

We did not migrate them off the official API for the writes they still needed; we moved the read-heavy collection to a flat-rate model and switched polling to event-driven collection. On the official API's per-resource pricing, that read volume sat in the awkward zone between cheap pay-per-use and a $42,000 Enterprise contract. Because our flat plans run up to 50x cheaper per read than the official API at that volume, the read side of their bill dropped into the low hundreds a month, and the 429s disappeared once the per-endpoint windows were out of the picture. The write path stayed on the official API, where it belongs.

Frequently asked questions

Are X API rate limits per user or per app?

Both, depending on the endpoint and your authentication method. Bearer Token (app-only) auth uses per-app limits, where every request from your application shares one pool. OAuth user-token auth uses per-user limits, where each authenticated user gets an independent bucket. Many endpoints publish both a per-app and a per-user figure; some publish only one. X's official rate-limit tables specify which applies to each endpoint.

What is the rate limit for posting on the X API?

The API write endpoint (/2/tweets) allows 100 posts per 15 minutes per user and 10,000 per 24 hours per app, and deleting is capped at 50 per 15 minutes per user. In practice the account-level cap binds first: an unverified X account is limited to 50 original posts and 200 replies per day across API, web, and mobile combined.

What is the rate limit for X API search?

Recent search (/2/tweets/search/recent) allows 450 requests per 15 minutes per app and 300 per 15 minutes per user, returning up to 100 results each with a 512-character query limit. Full-archive search (/2/tweets/search/all) allows 1 request per second with a 15-minute ceiling of 300, returns up to 500 results per call, reaches back to 2006, and is paid-plan only.

How long do X API rate-limit windows last?

Most X API v2 endpoints use 15-minute rolling windows. Some use 24-hour windows, including the posting endpoint (10,000 per 24 hours per app), media uploads, and several DM caps, and a few streaming and archive endpoints add a per-second cap. Each window starts from your first request to that endpoint, not from a fixed clock time.

Does the X API have a free tier with usable rate limits in 2026?

No. X discontinued the standalone free tier in February 2026, and new developers start on pay-per-use with no free allowance. The legacy free tier was write-only, capped at 17 requests per 24 hours on the post endpoint with zero post-read access, so it never supported reading X data at scale. The only free access now is an approval-gated program for designated public-utility apps. For testing read access without paying, Sorsa API includes 100 free requests on signup: one-time, no card required, they never expire, and they cover all 40 endpoints.

Are X's account limits the same as its API rate limits?

No, they are separate systems. API rate limits govern how fast a developer app can call each endpoint (for example, 100 posts per 15 minutes per user). Account limits govern what an X account can do platform-wide (for example, 50 original posts per day for an unverified account). Crucially, account limits count API actions too, so automated posts and manual posts share one daily budget.

Can I raise X API rate limits without Enterprise?

Not on the official API. Standard rate limits are fixed and only rise under an Enterprise agreement. The available workarounds are batching (more data per request), streaming (avoiding polling), and distributing requests across app and user auth. Beyond the official API, third-party read-focused providers typically apply a single flat per-second limit instead of per-endpoint windows, and will raise it on request.

How do developers get high read throughput without an Enterprise contract?

Most move read-heavy work to a Twitter/X API alternative with a flat rate limit instead of per-endpoint windows. Sorsa API, for example, serves all 40 of its read endpoints at 20 requests per second on every plan, from $0.02 per 1,000 tweets on batch endpoints, with plans starting at $49 a month. At read scale that lands up to 50x cheaper per post read than the official API's per-resource pricing, and it removes the 15-minute windows and the per-app versus per-user split that cause most 429s in collection pipelines.

Getting started

If the per-endpoint windows and the 429s 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 gets you authenticated with a single API key in a few minutes, and every new account includes 100 free requests: one-time, no card required, 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 plans run from $0.02 per 1,000 tweets on batch endpoints, with plans from $49 a month at the flat 20 requests per second covered above. 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: every endpoint figure here was read straight from X's official rate-limit tables and the account-level caps from X's limits documentation, both re-checked on July 31, 2026, because these numbers change without much notice (X cut the unverified daily post cap from 2,400 to 50 as recently as May 2026, and moved engagement writes to Enterprise-only in April 2026). The throughput math, the 429-recovery code, and the "which limit hits first" framing come from our own work building and operating an alternative Twitter/X API and from the read-pipeline migrations our team handles, including the anonymized fintech case above (details merged and stripped of anything identifying). Pricing and usage-cap claims are summarized from our separate X API pricing coverage; for who we are and how to reach us, see About Sorsa. No statistics, sources, or client outcomes here are invented.