X API rate limits: which one actually stops you

#Quick answer

X API rate limits are set per endpoint, not per account, and most of them use a 15-minute window. The headline numbers are 300 recent searches per 15 minutes on a user token, 100 post creates per 15 minutes per user against 10,000 per 24 hours per app, 50 per 15 minutes on nearly every write, and 15 per 15 minutes on every Direct Message lookup.

But the ceiling in that table is rarely the thing that breaks your project. Reads run out of money long before they run out of requests. Writes ran out of permission in April 2026. The rate limit genuinely binds in three narrow places, and knowing which meter you hit is the difference between a retry that works and a retry loop that never clears.

#The two meters, and why topping up does nothing

X runs request frequency and request volume as separate systems. The rate limit page says so directly: rate limits control request frequency for system stability, usage billing charges for data retrieved, and you can be inside one while exhausting the other.

That has a consequence most guides get backwards. On the old subscription model, a bigger plan bought a bigger window, so "upgrade to fix 429s" was real advice. Under pay-per-use it is not. Credits buy you more requests in total, never more requests per minute. The published per-endpoint numbers are what a self-serve key gets regardless of balance, and X's own page sends you to an account manager if you need them raised, which is the Enterprise conversation with no published price. If you are still working out what the volume side costs, X API pricing has the full rate card and five worked monthly bills.

One useful exception: X staff confirmed in September 2026 that x-rate-limit-limit reflects your own plan's value. The published table is the self-serve contract. The header is the truth for your key.

#A 429 means one of two unrelated things

This is the single most expensive thing to not know, and no page currently ranking for this query says it.

X's response-code reference defines 429 as "Too Many Requests: Rate limit or usage cap exceeded." One status, two completely different failures:

So read the headers before you back off. A retry loop that sleeps on a cap-exhaustion 429 will sleep forever, burn its retry budget, and report a transient error for something that needs a billing action. The body does not disambiguate either: the documented payload is a bare code: 88, "Rate limit exceeded", which is the same text in both cases.

X caps self-serve accounts at 3 million post reads per billing cycle, tracked at the app level across post lookup, both search endpoints, filtered stream, timelines, liked posts, bookmarks, list posts and Spaces lookup.

#Per-app and per-user are different buckets, and sometimes inverted

A bearer token draws on the per-app limit. An OAuth 1.0a or OAuth 2.0 user token draws on the per-user limit, and every authorised user gets their own bucket. That part is well covered elsewhere, usually framed as "user auth multiplies your capacity."

On several endpoints it does the opposite:

Pulling one account's timeline on a user token when a bearer token would do costs you an order of magnitude of throughput. The reverse is true on single-post lookup. There is no rule of thumb here, only the table, which is why it is worth checking the specific endpoint before you pick the token.

Two caveats keep this honest. Read-your-own-data endpoints are also the ones billed at the cheaper owned-read rate, which requires a user token, so the cheapest request is sometimes the slower one. And plenty of endpoints have a dash in one column: GET /2/users/me is user-only, filtered stream is app-only. X API OAuth has the scope and method split if you are deciding which flow to build.

#The 50-per-15-minutes write wall

Nearly every write a self-serve key can still make sits at 50 requests per 15 minutes per user:

• DELETE /2/tweets/:id
• POST and DELETE /2/users/:id/retweets
• PUT /2/tweets/:tweet_id/hidden
• POST and DELETE /2/users/:id/muting
• POST and DELETE /2/users/:id/bookmarks
• POST and DELETE /2/users/:id/followed_lists
• POST and DELETE /2/users/:id/pinned_lists

Fifty per quarter hour is 200 an hour, 4,800 a day in theory. That is the real throughput ceiling on anything that reaches out and touches other people's content, and it is low enough that it changes designs. A moderation bot hiding replies on a viral thread will meet it, which is why the X Hide Replies API is worth reading before you build one, since it carries a second ceiling on hidden replies per conversation that is not in the docs at all.

Post creation is the asymmetric one: 100 per 15 minutes per user, 10,000 per 24 hours per app. For a single-account bot the app number binds, because 100 per 15 minutes would be 9,600 a day anyway. For a product posting on behalf of customers, that 10,000 is shared, so around 100 active users at 100 posts a day exhausts the whole app. Note these are the API's limits and not the ones that apply when you post in the app; X daily limits covers that separate system.

#The table is not a capability list

X's rate limit page still publishes numbers for POST /2/users/:id/likes at 50 per 15 minutes plus 1,000 per 24 hours, and POST /2/users/:id/following at 50 per 15 minutes.

Neither is callable on a self-serve key. X's changelog entry of 16 April 2026 states that Following, Likes and Quote-Posts via the API were removed from all self-serve tiers effective 20 April 2026. The numbers stayed in the table because Enterprise still has those endpoints.

This trips up AI answers and tutorials constantly, because a rate limit table reads like a menu. It is not one. A published limit tells you how fast an endpoint may be called by someone who is allowed to call it. Permission is decided elsewhere, and the X API reply rules are the clearest example: POST /2/tweets has a generous limit and a condition that silently rejects most replies with a 403.

#Why reads almost never hit the rate limit

Run the arithmetic on recent search. An app-only token gets 450 requests per 15 minutes at up to 100 results each, so 45,000 posts a quarter hour, 180,000 an hour. At the published $0.005 per post read, that window permits roughly $900 an hour of spend.

Full-archive search is worse. Its 300 requests per 15 minutes at 500 results each is 150,000 posts a window, which would run through the entire 3 million monthly cap in about five hours of continuous pulling. The cap at $0.005 is a $15,000 bill, so for any read-heavy project the budget is the binding constraint by an enormous margin, and the rate limit is a formality.

That is why the useful optimisations are the billing ones rather than the pacing ones. X charges for a given resource once per 24-hour UTC day however many times you request it, so polling is cheap and breadth is expensive. For a listening tool, see X API search for which of the two search endpoints bills what.

Where volume genuinely matters, stop polling. Filtered stream is 50 connection attempts per 15 minutes, one concurrent connection and 250 posts a second of throughput. The X Activity API gets two connections at the same throughput and delivers per-user events by webhook. Neither charges you a request per post, so the frequency meter stops mattering and only the volume meter remains.

#The three places it genuinely binds

After all that, there are exactly three spots where the published rate limit is the thing you have to design around.

Direct Message lookups. All four of them sit at 15 per 15 minutes on a user token, which is one call a minute. Sending is 1,440 per 24 hours, which averages to one a minute as well. Any DM feature is pacing-bound from the first line of code.

Chunked media upload. Initialize, append and finalize each allow 1,875 per 15 minutes per user. X staff confirmed in September 2026 that a 16 GB file at 8 MB segments is about 2,048 appends, so one upload spans roughly two windows. The saving grace is that the session stays valid for 24 hours and re-sending the same segment_index after a 429 is safe, because the server overwrites that segment. X API media upload has the full four-call flow.

The 50-per-15-minutes write wall. Covered above, and the only one of the three that caps a growth use case rather than a technical one.

#Reading the headers properly

Three headers come back on every response:

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

x-rate-limit-reset is a Unix timestamp, not a duration. Sleep until it rather than assuming 15 minutes from your first call, because windows are not aligned to your process start:

import time, requests

def get(url, headers, attempt=0):
    r = requests.get(url, headers=headers)
    if r.status_code != 429:
        return r
    remaining = int(r.headers.get("x-rate-limit-remaining", -1))
    if remaining > 0:
        # Window is healthy, so this is a usage cap or credit failure.
        raise RuntimeError("429 with headroom left: check the Developer Console")
    reset = int(r.headers.get("x-rate-limit-reset", 0))
    time.sleep(max(reset - time.time(), 2 ** attempt))
    return get(url, headers, attempt + 1)

The remaining > 0 branch is the part worth copying. It turns the ambiguous 429 into two distinct outcomes instead of one slow retry.

Your own numbers are visible in the Developer Console alongside credit balance and per-endpoint usage, and the header beats the published table whenever they disagree.

#If you are building growth automation

None of this is a reason to pick the API or avoid it, but it does narrow what the API is for. Reads, your own analytics, internal integrations and genuinely novel apps are what it does well, and it is the sanctioned route for all of them. Engagement automation is a different question now: likes and follows left self-serve in April 2026, replies need the author to summon you, and what remains caps at 200 actions an hour.

Browser-based tools like X-Autopilot work from your own session instead of an API key, which sidesteps the rate limit table entirely and also sits outside what X's developer platform sanctions. Automating engagement through a browser is a gray area rather than an approved path, and X's automation rules govern the account whichever route you take. Running on your own machine and your own residential IP gives a lower detection surface than a shared cloud IP pool, not an absence of risk, and account-level limits still apply to everything you do. That tradeoff is the real decision, and the rate limit table only tells you half of it.