X API Rate Limits 2026: Per-Endpoint Table and 429 Fix
The current X API rate limits per endpoint, app versus user tokens, the x-rate-limit headers, and a tested Python loop that waits for the reset.
Tarun Khatri
Published · Updated · 7 min read
X API rate limits cap how many requests each endpoint accepts in a time window, which is usually 15 minutes.
This guide is for developers who keep getting 429 Too Many Requests from the X (Twitter) API. You get X's current limits, the headers, and a retry loop we tested.
Check your budget on an endpoint with one call, which X bills as one user read:
curl -s -D - -o /dev/null "https://api.x.com/2/users/by/username/XDevelopers" \
-H "Authorization: Bearer $X_BEARER_TOKEN" | grep -i x-rate-limit
X API rate limits per endpoint (October 2026)
These are the read endpoints people ask about most, from X's rate limits page on 22 October 2026. Each number is per 15 minutes:
| Endpoint | Per app | Per user |
|---|---|---|
| Recent search | 450 | 300 |
| Full-archive search | 300 | 1 a second |
| User lookup, by id or username | 300 | 900 |
| User posts timeline, by id | 10,000 | 900 |
| Mentions timeline | 450 | 300 |
| Followers or following | 300 | 300 |
| Post lookup, many ids | 3,500 | 5,000 |
Full-archive search also allows just 1 request a second on an app token.
One row hides a trap. The timeline by username gets 1,500 per app, not 10,000, so look up the numeric id once and reuse it.
Daily limits sit mostly on writes. An app can create 10,000 posts a day, and each user can like 1,000.
App limits versus user limits: which one are you using?
Your token decides the column. X's page says per-app limits apply with a bearer token, and per-user limits with OAuth 1.0a or OAuth 2.0 user tokens.
- A bearer token shares one budget per endpoint across your whole app.
- User tokens count each signed-in user on their own.
Neither column is always bigger. User lookups give more per user, while the posts timeline gives far more per app.
How to read the x-rate-limit headers
Every X API response carries three headers. This example is from X's docs:
x-rate-limit-limit: 900
x-rate-limit-remaining: 847
x-rate-limit-reset: 1705420800
x-rate-limit-limitis the window's full budget for this endpoint.x-rate-limit-remainingis what's left. At 0, your next call gets a 429.x-rate-limit-resetis a Unix timestamp in seconds, when the window refills.
For a wait time, subtract the current time from the reset and add a second of slack.
Rate limit, monthly cap or no credit: three different stops
X can refuse a request for three reasons, and only one clears when the window resets:
- Rate limit, a 429. Too many calls in the window. Wait until
x-rate-limit-reset. - Monthly usage cap, also a 429. X's pricing page caps pay-per-use plans at 3 million post reads per billing cycle. The error type ends in
usage-capped. - No credit left, a 402. Only a purchase fixes it, as our X API 402 Payment Required guide explains.
Your own spending limit is a fourth stop. X's pricing page says it blocks requests until the next billing cycle.
Rate limits and billing are separate. X's rate limits page says you can stay within them "but still incur usage costs."
How to fix x api 429 too many requests: wait for the reset
Sleep until the reset, cap the tries, and stop on the monthly cap. This function also pauses when remaining hits 0, so most 429s never happen:
import time, requests
def sleep_until_reset(r):
reset = int(r.headers.get("x-rate-limit-reset", time.time() + 60))
time.sleep(max(reset - time.time(), 0) + 1)
def x_get(url, headers, params=None, tries=4):
for _ in range(tries):
r = requests.get(url, headers=headers, params=params, timeout=30)
if r.status_code != 429:
if r.headers.get("x-rate-limit-remaining") == "0":
sleep_until_reset(r) # the next call would get a 429
return r
if "usage-capped" in r.text:
raise RuntimeError("Monthly cap hit: a window reset won't clear it.")
sleep_until_reset(r)
return r
X's own example waits at least 60 seconds every time. This one waits only as long as the reset says.
We tested it on 22 October 2026 against a local stub that sends X's headers. Its window was 3 calls per 10 seconds, so the test ran fast:
15:41:16 NASA 200 remaining 2
15:41:16 github 200 remaining 1
15:41:28 XDevelopers 200 remaining 0
15:41:28 Google 200 remaining 2
The third call used the last request, so x_get slept until the reset before returning it.
Pushed into a real 429, it waited 12 seconds and got a 200. Given a usage-capped body, it stopped at once.
Other codes, and Tweepy's wait_on_rate_limit, are in our guide to X API error codes.
What X's rate limits page doesn't tell you
We looked for these on 22 October 2026 and couldn't find them:
- How the window counts. X gives a reset time, not whether windows are fixed or rolling.
- What a capped 429 carries. X doesn't say what
x-rate-limit-resetmeans there. - The spending limit's status code. X describes the block, not the code.
- Enterprise numbers. Enterprise limits are custom, and none are published.
When in doubt, trust the headers on your own responses.
Weir's rate limits: one budget a minute, billed per result
We run Weir, a read-only API for public X and Reddit data, so weigh this section knowing that. Weir has no endpoint windows. One budget per minute covers every call, and you pay per result.
The budget grows with what you've bought in total:
Heavier calls count for more. A search counts as 2, so the free tier fits 15 searches a minute.
Each metered response carries ratelimit-limit, ratelimit-remaining and ratelimit-reset. A 429 adds Retry-After, in seconds:
import os, time, requests
HEADERS = {"Authorization": f"Bearer {os.environ['WEIR_API_KEY']}"}
def weir(method, path, tries=4, **kwargs):
for _ in range(tries):
r = requests.request(method, f"https://api.weirapp.io{path}",
headers=HEADERS, timeout=60, **kwargs)
if r.status_code != 429:
return r # a 402 is never retryable: stop and add credits
wait = int(r.headers.get("Retry-After", "5"))
print(f" 429, Retry-After {wait}s")
time.sleep(wait)
return r
We sent 17 searches through it to a stub that copies Weir's limiter code, at the free tier's 30 a minute. Fifteen went through, then:
16:00:15 15 200 0
429, Retry-After 49s
16:01:04 16 200 0
429, Retry-After 4s
16:01:08 17 200 0
Each retry after a wait went through. Weir's window slides, so the first wait ran a few seconds past the minute while the earlier burst faded.
A refused call costs nothing on Weir. The Weir errors guide lists every code.
When not to use Weir
- You need to post, like or follow. Weir only reads, so writes need X's own API.
- You need a contract with X itself, or Enterprise volume above the monthly cap.
- You read your own account. X prices owned reads at $0.001 each, as of October 2026.
- Cost per post is all you care about. TwitterAPI.io lists $0.15 per 1,000 tweets, below Weir's smaller packs.
Weir is not affiliated with X, so access can change. See Weir vs the official X API for the full comparison.
FAQ
What is the rate limit for the X API?
It depends on the endpoint and the token. Recent search allows 450 requests per 15 minutes with an app token and 300 per user. User lookups allow 300 per app and 900 per user. X lists every endpoint on its rate limits page.
How long does an X API rate limit last?
Until the time in x-rate-limit-reset, which is 15 minutes or less for most reads. Some limits count per day. The monthly usage cap counts per billing cycle, so its 429 won't clear at the next window.
Are Twitter API rate limits per app or per user?
Both. A bearer token draws on your app's budget for that endpoint, and a user token draws on that user's own budget. X lists both numbers for each endpoint, and they often differ.
Does a 429 cost money on the X API?
No. X's usage and billing page says only successful responses that return data are billed. A 429 returns no data, so it's free. It still costs you time.
Sources
All checked on 22 October 2026:
- X API rate limits: https://docs.x.com/x-api/fundamentals/rate-limits
- X API response codes and errors: https://docs.x.com/x-api/fundamentals/response-codes-and-errors
- X API usage and billing: https://docs.x.com/x-api/fundamentals/post-cap
- X API pricing: https://docs.x.com/x-api/getting-started/pricing
- X pay-per-use developer agreement, section D: https://docs.x.com/developer-terms/ppu-agreement
- TwitterAPI.io pricing: https://twitterapi.io/pricing
- Weir errors and rate limits: https://docs.weirapp.io/errors
- Weir billing and tiers: https://docs.weirapp.io/billing
- Our runs against local stubs of X's headers and Weir's limiter, 22 October 2026