X (Twitter) API Rate Limits 2026: Every Endpoint Explained

By Sorsa Editorial

Updated June 2026: reflects X's May 2026 cut of the unverified daily post cap from 2,400 to 50 original posts (plus 200 replies), notes the April 20, 2026 removal of self-serve following, likes, and quote-posts (now Enterprise-only), adds a free-tier rate-limit breakdown, and re-verifies every endpoint limit against X's official rate-limit tables.

There is a second, quieter layer most rate-limit guides miss. Your developer app sits under the X API's per-endpoint limits, but 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 on top of both. Hitting any one of the three returns the same 429, which is why "I'm nowhere near my rate limit" is such a common and confusing complaint.

This guide walks through all three layers with current numbers, verified against X's own documentation. 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 that run far cheaper than the official per-resource pricing. 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 so you can see exactly what changes.

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

Table of Contents

• How X API rate limits work
• Rate limits for the most-used endpoints
• Posting limits: API caps vs account caps
• Does the X API free tier have usable rate limits?
• Account limits: unverified vs verified accounts
• How many tweets can you actually pull per day?
• Standard vs Enterprise rate limits
• What happens when you hit a rate limit
• 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; a few, such as posting and media upload, use 24-hour windows. Every endpoint tracks two independent pools: a per-app limit for Bearer Token (app-only) auth and a per-user limit for OAuth user-token auth.

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, not 300 reset on the quarter hour.

Per-app vs per-user limits

Per-app limits apply when you authenticate with a Bearer Token. 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 requests per 15 minutes for recent search.

Some endpoints expose both limits, some only one. X's official rate-limit tables list both columns for every endpoint, and a dash 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 if you are running low. You never have to guess.

Rate limits are not the same as usage caps

This distinction trips up a lot of developers. Rate limits control how fast you can call the API. Usage caps control how much data you can consume per billing cycle. They are tracked separately and enforced separately.

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

Rate limits for the most-used endpoints

The official documentation covers 80-plus endpoints across a dozen categories. The tables below cover the ones developers actually call day to day, with both the per-app and per-user limit and the window for each. All figures are taken directly from X's official rate-limit documentation and re-checked in June 2026.

Read endpoints

Write endpoints

Direct message and streaming endpoints

One change matters for anyone automating engagement: effective April 20, 2026, X removed following, likes, and quote-posts from all self-serve tiers, so the write limits above for those actions now apply only under an Enterprise contract (per X's API changelog). Posting and direct messages stay available on pay-per-use.

A few of these deserve a closer look.

Search splits into two endpoints with very different ceilings. Recent search (/2/tweets/search/recent) 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 (/2/tweets/search/all) reaches all the way to 2006 but caps you at 1 request per second with a 15-minute ceiling of 300. If you need historical depth, full-archive is the only option, and that 1/sec hard cap means you cannot burst. We cover working within it in our guide to pulling historical Twitter data.

Follower and following endpoints share one limit. Both run 300 per 15 minutes, per app and per user. At 1,000 results per page, paginating a million-follower account takes roughly 16 to 17 windows, or about four hours of wall-clock time. If pulling followers and following lists at scale is your core workload, that pacing is the number to plan around, and it is one of the clearest cases where a flat per-second limit collects the same graph in minutes rather than hours.

Direct message reads are tight. At 15 requests per 15 minutes per user, DM-heavy workflows hit their ceiling fast, and the per-user-per-24-hours caps on sending make automation here deliberately slow.

Posting limits: API caps vs account caps

X enforces posting on two separate layers in 2026. The API write endpoint (/2/tweets) allows 100 posts per 15 minutes per user and 10,000 per day per app. Separately, the X account you post from is bound by account-level caps that apply across web, mobile, and API alike. For unverified accounts that account cap dropped to 50 original posts and 200 replies per day in May 2026 (down from a long-standing 2,400), far lower than the API limit and usually what actually stops an automation.

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

Here is how the two layers interact in practice:

• Unverified account + API automation: the account cap of 50 original posts per day hits long before the API's 100-per-15-minutes window matters. Replies are capped separately at 200 per day.
• Verified or Premium account + API automation: the account-level post cap is higher (X does not publish the exact number for Premium), so the API write limit (100/15min per user, 10,000/24hrs per app) becomes the real ceiling.
• App-level scale: even with many verified users, the per-app 10,000 posts per 24 hours is a hard wall for high-volume publishing.

X's own account-limit documentation is explicit that these account caps count actions "from all devices, including web, mobile, phone, API," so API posts and manual posts draw from the same daily pool. The two layers are not additive. The 2,400-posts-per-day figure still quoted across most other guides was the ceiling through April 2026; X cut it to 50 original posts and 200 replies for unverified accounts in May 2026, and reposts and quotes are widely reported to count toward that 50, though X has not stated so outright. X's own help page still references the old 2,400 number in places, so you will see both in the wild, but 50 is the current enforced cap.

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.

Does the X API free tier have usable rate limits?

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, and it is not something to plan a product around.

For anyone still holding a legacy free-tier app, the rate-limit picture was always severe by design. The legacy free tier was write-only, measured in 24-hour windows rather than the friendlier 15-minute windows, and allowed only a small daily quota of posts (in the low tens per day, depending on the period) with zero post-read access. You could not pull timelines, search, or look up posts at all.

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 today is a third-party playground. Our own API playground runs live endpoints in the browser with no key and no signup, which is enough to confirm the data shape fits before anyone pays for anything. For the full cost and access story, including the migration voucher and what replaced the tiers, see our full cost breakdown.

Account limits: unverified vs verified accounts

Separate from developer API access, every X account operates under platform-wide caps that X enforces to keep the system stable. In May 2026 X tightened these sharply for unverified accounts, cutting the daily post ceiling from 2,400 to 50, while verified (Premium) accounts are largely exempt or given higher ceilings.

The current published account-level limits are:

Two details matter for anyone building on top of an account. First, the post and reply caps are broken into smaller semi-hourly intervals, so 50 posts does not mean 50 in one burst. Second, and this is the part that surprises people, these caps count API actions too: per X's limits documentation, the daily limits include actions from web, mobile, and API together. Your script and your phone share the same daily post budget.

If your goal is reading public X data rather than acting as an account, these account-level caps do not apply to you at all, because read access through a developer app is governed by the API rate limits and usage cap in the sections above, not by per-account posting and follow limits.

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 your 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 scraping individual timelines, rate limits are rarely the constraint. The real limit is how many tweets the account has posted; most accounts have a few thousand total.

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 endpoints. For comparison, on our 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 and for high-concurrency pipelines on app-only auth with its lower per-app numbers.

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)
• Dedicated infrastructure and support
• Full-archive search at higher concurrency
• 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 sentiment 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 — 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:

For read-heavy collection, that works out to roughly 30 to 50 times cheaper per read on Sorsa, 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. So 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

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.

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 (/2/tweets/search/stream) pushes matching tweets to you in real time over a single persistent connection: one connection, one rate-limit hit, up to 250 matching posts per second. The catch is that filtered stream allows 50 connection attempts per 15 minutes and only 1 active connection at a time, but for monitoring keywords or accounts it is far more efficient than polling. We go deeper on this 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 (likes, retweets, replies) move faster, so a 1-to-6-hour TTL is usually the right balance 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, for example, 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.

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 roughly 30 to 50 times 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.

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 with only a small daily post quota and zero post-read access, measured in restrictive 24-hour windows, so it never supported reading X data at scale. The only free access now is an approval-gated program for designated public-utility apps.

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. A few use 24-hour windows, including the posting endpoint (10,000 per 24 hours per app) and media uploads. Some engagement write endpoints used 24-hour windows too, before X moved following, likes, and quote-posts to Enterprise-only access in April 2026. Each window starts from your first request to that endpoint, not from a fixed clock time.

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. Third-party providers are more flexible here: an alternative X API like Sorsa applies a single 20-requests-per-second limit on every plan and will raise it on request, with no per-endpoint windows to manage.

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 starting at $49 a month, with batch endpoints that return up to 100 tweets or profiles per request. At read scale that lands around 30 to 50 times 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 pricing plans start at $49 a month for 10,000 requests 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: the endpoint figures here were read straight from X's official rate-limit tables and the account-level caps from X's limits documentation, both re-checked on June 6, 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). 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.