X Stopped Publishing Twitter API Rate Limits by Tier

What are the Twitter API rate limits in 2026?

Nothing in X's current documentation sets Twitter API rate limits by plan tier. The live tables are organised by endpoint and split into two columns, one for per-app limits that apply when you authenticate with a bearer token and one for per-user limits that apply under OAuth 1.0a or OAuth 2.0 user tokens. Every figure below comes from docs.x.com/x-api/fundamentals/rate-limits, read on 12 September 2026.

Windows are 15 minutes unless the entry says otherwise. These are the endpoints a listening or monitoring build actually touches.

Two entries in that table are worth staring at. Recent search gives an app 450 requests but a user only 300, so the app-only bearer token is the stronger credential for monitoring. Full-archive search is governed by a per-second limit as much as a per-window one, which means a backfill job needs a sleep between calls rather than a burst and a wait.

Which tiers do the Twitter API rate limits apply to?

X runs two commercial levels now, pay-per-use and Enterprise, and the Free, Basic and Pro subscription tiers that older guides still quote are gone. The changelog dates the switch. X announced the pay-per-use pilot on 20 October 2025 and launched pay-per-use pricing on 6 February 2026 with Basic and Pro still available, then migrated Basic subscribers after 1 June 2026 and Pro subscribers after 1 September 2026. The rate limit tables above carry no tier column at all, which is the honest answer to "what are the limits on Basic". There is no Basic.

Where X does still split by level, the numbers look like this.

Where does X contradict itself on these numbers?

Three live pages on docs.x.com disagree with each other, and the disagreements are not cosmetic.

The first is the filtered stream rule count. The filtered stream introduction page puts Enterprise at "25,000+" rules per project. The Enterprise pricing page, describing the same product, puts it at "5,000+ rules". Both pages were live on 12 September 2026 and neither links to the other as a correction.

The second is the query length on Post counts. The rate limit table lists /2/tweets/counts/all with a "1024 query length" note. The counts query builder page says "Your query can be 512 characters long for pay-per-use customers, or up to 4,096 characters for Enterprise customers", covering both counts endpoints with one number. A query written to 1,024 characters against /2/tweets/counts/all therefore sits inside one page's limit and outside the other's.

The third is a dangling reference. Both search query builders and the filtered stream rule builder tell you that your limits depend on your access level and link to /x-api/getting-started/about-x-api for the detail. That page no longer contains an access level section. It has capabilities, API versions, resources and pay-per-usage pricing, and nothing that names a tier. The page at docs.x.com/fundamentals/rate-limits carries the description "Understand X API rate limits across access tiers and endpoints" and then lists no tiers, only a link out to the endpoint table.

The lesson for anyone budgeting a build is to treat the per-endpoint table as the operative document and the prose pages as stale.

How do you read the rate limit headers?

X returns three headers on every response, and they are the only real-time source of truth.

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 is left, and x-rate-limit-reset is a Unix timestamp for when the window rolls over. Cross the ceiling and you get a 429 with this body:

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

Error code: 88 has survived every rewrite of this API since v1.1, so it is worth matching on explicitly rather than on the status code alone. X's own recovery advice is to read x-rate-limit-reset, wait until that timestamp, and apply exponential backoff after that.

Are rate limits the same thing as your bill?

No, and X states the split directly: rate limits control request frequency for system stability, while usage billing charges for data retrieved. You can sit inside every rate limit and still spend, and you can hit a rate limit without spending anything extra.

Reads are charged per resource returned, not per request. A Post read costs $0.005 and a user read costs $0.010. Resources are deduplicated inside a 24 hour UTC window, so pulling the same Post twice in a day is charged once, and X calls that deduplication a soft guarantee rather than a promise. The pay-per-use plan is capped at 3 million Post reads per monthly billing cycle regardless of how gently you pace your requests. The full cost picture, including the write side, is broken down in the note on X API pricing.

Which limit actually stops a monitoring build?

The monthly Post read cap, not the per-window request limit. Recent search at 450 requests per 15 minutes with 100 results per request is 45,000 Posts a window on paper, which would exhaust a 3 million Post allowance in under a day of continuous polling. The request ceiling is generous; the resource ceiling is the budget.

That changes the shape of a good query. Narrow rules that return few matches cost little, and a broad rule that matches a common word burns the allowance while you sleep. Filtered stream is the cheaper instrument for continuous coverage because it delivers only what matches your rules, and the rules themselves are free to hold. Writing those rules well is the same skill as writing a good search query, which is covered in the reference on X advanced search operators.

The other half of the calculation is that X is one network. A buying question asked on X is usually asked on Reddit and Hacker News too, and those platforms meter access differently, as the comparison of Reddit API rate limits shows. Teams that started on the X API and then priced the coverage gap tend to end up doing listening across several networks rather than paying to widen one.

Frequently asked questions

What is the rate limit for the X search API?

Recent search at /2/tweets/search/recent allows 450 requests per 15 minutes with an app-only bearer token and 300 per 15 minutes with a user token, returning 10 results by default and 100 at most. Full-archive search at /2/tweets/search/all allows 1 request per second and 300 per 15 minutes per app, returning 10 by default and 500 at most.

Does X still have a Free tier?

Not as a documented product. X launched pay-per-use pricing on 6 February 2026 and its current getting-access documentation walks you through signing up, creating an app and saving credentials without naming a tier. The word "Free" survives only in changelog entries, including the 22 August 2025 note that removed POST /2/users/:id/likes and POST /2/users/:id/following from the Free tier.

What does HTTP 429 mean on the X API?

It means you exceeded a rate limit for that endpoint in the current window. The response body carries code: 88 and the message "Rate limit exceeded". Read the x-rate-limit-reset header for the Unix timestamp when the window resets, and do not retry before then.

Are rate limits counted per app or per user?

Both, and which one applies depends on how you authenticated. Bearer token requests count against the per-app limit, and OAuth 1.0a or OAuth 2.0 user token requests count against the per-user limit for that user. Several endpoints publish only one of the two columns, which means the other authentication mode is not offered there at all.

How many filtered stream rules can I run?

A pay-per-use project gets 1,000 rules of up to 1,024 characters each, over a single connection, with delivery capped at 250 Posts per second. Enterprise raises the rule length to 2,048 characters and allows multiple connections. The rule count for Enterprise is where X's own pages disagree, at 25,000+ on the filtered stream introduction and 5,000+ on the Enterprise pricing page.

Do rate limits apply to the usage endpoint itself?

Yes. GET /2/usage/tweets, the endpoint that reports your own Post consumption, is capped at 50 requests per 15 minutes per app and offers no per-user limit. Polling your own spend is cheap but not free of the accounting, so read it on a schedule rather than before every call.

How much does the X API charge per Post read?

A Post read costs $0.005 and a user read costs $0.010, charged per resource returned rather than per request. X deduplicates resources inside a 24 hour UTC window, so fetching the same Post twice in a day counts once, though X labels that deduplication a soft guarantee rather than a promise. The pay-per-use plan caps total Post reads at 3 million per billing cycle regardless of how those reads are paced.

When did X retire the Basic and Pro API tiers?

X launched pay-per-use pricing on 6 February 2026 with Basic and Pro still available, then deprecated both. Basic subscribers migrated after 1 June 2026 and Pro subscribers after 1 September 2026, leaving Enterprise and pay-per-use. Older guides that still quote Basic or Pro limits describe a pricing structure that no longer exists.

Why is the per-user rate limit higher than the per-app limit on some endpoints?

There's no single rule. On /2/tweets, a per-app bearer token gets 3,500 requests per 15 minutes while a per-user token gets 5,000, and /2/tweets/:id follows the same pattern at 450 versus 900. Recent search runs the other way, with 450 per app against 300 per user, so the stronger credential depends on the endpoint you're calling, not on a fixed hierarchy between app and user auth.

What's the cheapest way to run continuous X monitoring?

Filtered stream, not polling search. Recent search at 450 requests per 15 minutes with 100 results per call can return 45,000 Posts a window on paper, enough to burn a 3 million Post monthly allowance in under a day of continuous polling. Filtered stream delivers only what matches your rules, and holding those rules costs nothing, so a well-scoped rule set covers the same ground for a fraction of the reads.