Which Twitter API publishes its rate limits in a comparable unit?

Which Twitter API publishes its rate limits in a comparable unit?

TwitterAPIs.com does: one figure, 600 requests a minute per key with 20 running concurrently, identical on every endpoint in the catalogue. X publishes limits thoroughly but not comparably, a separate number for each endpoint, split into a per app and a per user column, over windows that are sometimes 15 minutes and sometimes 24 hours. Both are honest. Only one of them lets you answer a question like how many accounts can I enrich in an hour without first building your own conversion table. The rest of this page sets out what comparability means, how X's tables are actually shaped, where the single figure helps and where it does not, and how to verify any published limit against the account you are really using.

What does a comparable rate limit unit actually mean?

A rate limit is comparable when one number tells you what your whole integration can do. That is a stricter test than publishing limits at all, and almost every provider passes the weaker test while failing the stronger one. X documents its limits thoroughly, endpoint by endpoint, and the documentation is genuinely good. It is still not comparable, because the unit changes underneath you as you move across the surface. Recent search is quoted per 15 minutes. Post creation is quoted per 24 hours. Filtered stream is quoted per 15 minutes and then qualified further by a connection count and a posts per second ceiling. To answer a question as ordinary as how many accounts you can enrich in an hour, you have to open the table, find your endpoint, pick the column that matches your token type, and convert the window. Do that for four endpoints and you have four numbers in three units, none of which combine.

How does X publish its API rate limits?

X splits every row into a per app column and a per user column, because the ceiling depends on whether you authenticate with a Bearer token or with a user token. Recent search allows 450 requests per 15 minutes per app and 300 per user. Full archive search is 1 per second alongside 300 per 15 minutes. Mentions on a user timeline allow 450 per 15 minutes per app and 300 per user, while the same data read through the by username route allows 180 per user. Post creation is 10,000 per 24 hours per app but only 100 per 15 minutes per user. Every one of those figures is accurate and none of them is wrong. The problem is that they are not the same measurement, so an architecture decision that touches several endpoints cannot be sized without building your own conversion table first. The windows themselves are not uniform either: the documentation says a window is usually 15 minutes or 24 hours, and usually is doing real work in that sentence.

Why are X rate limits quoted per 15 minutes and per 24 hours?

The window follows what the endpoint is protecting, which is a defensible design even though it is what makes the numbers incomparable. Read endpoints are throttled on a short window because the risk they carry is burst load, a scraper hammering search for ninety seconds. Write endpoints such as post creation, likes and follows carry daily caps because the risk there is sustained abuse rather than a spike, and a 15 minute window would not constrain it. That is why post creation shows 10,000 per 24 hours on an app token but only 100 per 15 minutes on a user token, and why you cannot add the two figures together or convert one into the other. Converting a daily cap into a 15 minute equivalent assumes an even spread across the day that no real workload has, so the converted number is always wrong in the direction that matters, which is the peak.

What is the rate limit on TwitterAPIs.com?

TwitterAPIs.com quotes 600 requests a minute per key, with 20 running concurrently, and that figure is identical on every endpoint in the catalogue. Search is 600 a minute. Follower pagination is 600 a minute. Posting is 600 a minute. Because the number does not move, you can size a job before you know which endpoints it will touch, which is the practical difference between a comparable unit and a complete one. Concurrency is usually the binding constraint rather than the per minute ceiling, because 20 slots at a typical response time will not reach 600 in a minute on most workloads. The right shape is a fixed pool of 20 workers draining a queue. Firing 200 requests at once does not make any single one return sooner, and it is the fastest way to see a 429 that your own client caused.

Does one number for every endpoint mean the limit is looser?

Not necessarily, and the two questions are worth keeping apart. A uniform limit is easier to reason about, not automatically higher. On a heavy search workload 600 a minute is more generous than X's 450 per 15 minutes. On post creation X's per app figure of 10,000 per 24 hours is the more generous one if you can use an app token. Uniformity buys predictability rather than headroom, and predictability is what lets you size a job without a spreadsheet. Uniformity is a property of the shape rather than of the size, and the two are worth separating when you compare providers. Ask what the limit is, then ask how many different numbers you have to hold in your head to plan a job against it. A single figure that is slightly lower can still be easier to build against than a generous figure that changes on every endpoint you touch.

Which constraint binds first, requests per minute or concurrency?

Concurrency, on almost every real workload. Twenty slots occupied for the length of a round trip will not usually issue 600 requests inside a minute, so the per minute ceiling is rarely the wall you meet. Size your worker pool at 20 and let the queue absorb the rest. If you find yourself approaching 600 a minute, your responses are returning fast enough that concurrency has stopped binding, which is a good problem. The practical consequence is that a worker pool is the right shape and a fire-and-forget loop is not. Twenty workers pulling from a queue will saturate the concurrency slot cleanly and never approach the per minute ceiling on a typical response time, which means your throughput is governed by how fast responses come back rather than by any published number.

Are rate limits the same thing as my bill?

The most expensive misreading in this area is treating a rate limit as a spend ceiling. X states the separation plainly in its own documentation: rate limits control request frequency for system stability, while usage billing charges for data retrieved. You can sit comfortably inside every limit and still run up a bill, and you can hit a limit having spent nothing extra. On a subscription tier that distinction bites in a specific way, because the post allowance runs out on a different schedule from the request window, and the allowance is what actually stops your job. On a metered rate card the two are cleanly separate by construction: the limit governs pace, the price governs volume. Model them as two independent budgets whichever provider you choose, and alarm on both.

What happens when you cross a Twitter API rate limit?

You get HTTP 429 and should back off until the window resets rather than retrying immediately. On X, read x-rate-limit-reset for the exact unix timestamp and wait for it, using exponential backoff if you are still being refused after that. Retrying a 429 in a tight loop is worse than useless, because on some setups the retries themselves keep the window saturated and you never recover. Treat 429 as a scheduling signal, not an error to swallow. Build the backoff into the client rather than into each call site, so every endpoint inherits the same behaviour and a new integration cannot forget it. Log the 429s rather than swallowing them: a rising 429 rate is the earliest signal that a workload has outgrown its pacing, and it is invisible if the retry succeeds quietly.

Is a 429 the same as being blocked?

No, and confusing them sends you down the wrong repair path. A 429 is a pacing refusal that clears on its own at a known time. A 401 or 403 is an authentication or permission problem that will not clear no matter how long you wait. If retries after the reset timestamp still fail, stop treating it as a rate limit and check the credential.

Which response headers show your remaining rate limit?

X returns three headers on responses: x-rate-limit-limit is the maximum for the window, x-rate-limit-remaining is what is left in it, and x-rate-limit-reset is the unix timestamp at which the window rolls over. Those three are worth more than the documentation page, because they describe the credential you are actually holding rather than the tier you believe you are on. Log the remaining value on every call for a day and take the floor. If that floor sits well under the documented number, something is dividing your budget: a shared key used by several processes, a negotiated agreement that differs from the public table, or an app token where you assumed a user token. All three are common and none of them announce themselves. A published limit is a claim about a tier; the header is a measurement of your key.

How do you check a published rate limit against your own account?

Read the response headers rather than the documentation page, because headers describe the account you are actually using. X returns x-rate-limit-limit, x-rate-limit-remaining and x-rate-limit-reset on responses, and a 429 carries code 88 with the message rate limit exceeded. Log the remaining value on every call for a day and compare the floor you observe against the number that was published. Three things commonly diverge: an enterprise or negotiated agreement raises a ceiling without the public table changing, a shared key means your effective budget is a fraction of the documented one, and a limit quoted per app behaves differently once several processes hold the same credential. A published limit is a claim about a tier. The header is a measurement of your key.

Data access compared

Limits only mean something next to what they let you read, so compare data access before comparing numbers. On this API one key reaches 121 endpoints, 71 reads and 50 writes, and every one of them sits under the same ceiling of 600 requests a minute with 20 in flight. Public reads, which cover search, timelines, profiles, followers, replies, quotes, lists, communities, Spaces and trends, need nothing but the key. Reads of private data, such as the home timeline, bookmarks, direct messages and followers-you-know, run as an X account whose session you register, and they count against the same per-key ceiling. On the official API, data access is split by product and by token: each endpoint carries its own window, app tokens and user tokens draw on separate budgets, and the volume you may read in a month is capped at 3 million posts before the next step is a negotiated contract. The practical comparison is therefore two questions rather than one. Can this key read everything the job needs? And how many separate limits stand between the job and finished? Here the answers are yes for public data, and one.

Third-party provider envelopes

Every third-party provider publishes its limits in its own envelope, so before comparing, rewrite each one into the same four fields. The unit: per second, per minute or per day, converted to per minute so they line up. The scope: per key, per account or per address, because a per-account limit shared across several keys is a smaller budget than it looks. The concurrency: how many requests may be in flight at once, which on most workloads binds before the per-minute figure does. And the refusal: what status comes back, which header says when to retry, and whether the refused request is billed. Ours, written in that envelope, reads 600 requests a minute, per key, 20 concurrent, a 429 carrying Retry-After, and no charge for the refused call. Two narrower caps sit beside it and are published rather than discovered: 150 direct message sends an hour per key on a sliding window, and 10 credential logins an hour. A provider that cannot fill in all four fields for you has not published a limit you can plan against, whatever number appears on its pricing page, and the gap usually shows up the first time a job runs at full speed.

The official API's monthly read cap

Beside its request windows, the official API has a second ceiling that matters more for large jobs: self-serve pay-per-use stops at 3 million post reads per monthly billing cycle. That cap limits volume rather than pace, so a job can respect every 15 minute window and still run out of month. Past it there is no bigger self-serve plan to move to; the next step is an Enterprise contract with no published price. Measured in the units of this page, 3 million posts at about 20 posts a call is 150,000 calls, which at a steady 600 requests a minute is a little over four hours of the per-minute ceiling here, and $120 at $0.0008 a call. The same volume on the official meter is $15,000 at $0.005 a post, before any user lookups are added. There is no monthly volume cap here at all. What bounds a month is pace, 600 requests a minute and 20 in flight, and your balance, which answers 402 when it runs out rather than letting spend grow past what you loaded. Plan large archives against those two numbers rather than against a calendar.

Quick comparison, limit by limit

Put the published figures into one unit, requests per minute, and the comparison becomes readable. On X, recent search allows 450 requests per 15 minutes on an app token, which is 30 a minute, and 300 on a user token, which is 20 a minute. Mentions on a user timeline allow the same 450 and 300. Full archive search allows 300 per 15 minutes, 20 a minute, with a hard floor of one request per second on top. Post creation allows 10,000 per 24 hours on an app token, about 7 a minute on a perfectly even spread, and 100 per 15 minutes on a user token, again about 7 a minute. Here every endpoint allows 600 a minute per key with 20 in flight, while direct message sends are capped at 150 an hour, 2.5 a minute, and logins at 10 an hour. Two caveats keep the comparison honest. Converting a daily cap into a per-minute figure assumes an even spread that no real workload has, so the converted number misstates what a burst can do. And X's limits count requests while X's bill counts posts, so on the official side a request returning many posts costs more than one returning a single post, while here both cost the same.

One-time data collection

A one-time pull is where a single per-minute figure earns its keep, because you can size the job before writing it. Take a one-off collection of 100,000 posts. At about 20 posts a call that is 5,000 requests. At the full 600 a minute the floor on wall clock is a little over eight minutes, and in practice concurrency binds first, so twenty workers draining a queue finish when the responses allow rather than when a window resets. The bill is 5,000 calls at $0.0008, which is $4.00, and it is the same whether you run the job today or spread it across a week. Sparse collection changes the arithmetic but not the method: 5,000 single-post lookups through tweet/detail are also 5,000 requests and also $4.00, because the price follows the call rather than the number of posts it returns. On a per-resource meter the dense pull is 100,000 post reads at $0.005, $500, and the sparse one is 5,000 reads, $25, which is why the unit decides the bill for one-time work more than the rate does. Write the request count down first; the time and the cost both follow from it.

Evaluating providers by workload

A fair evaluation runs the same workloads through every provider's published limits rather than comparing headline numbers. Pick three shapes that match real use. A burst: 2,000 search requests needed within ten minutes for a breaking story. A steady enrichment: 20,000 profile lookups spread across a working day. An archive: 50 accounts, full history, once. For each provider, convert the published limits into the time each workload needs and note which limit binds, whether that is the per-minute ceiling, the concurrency, a daily cap or a monthly volume cap. Here the burst needs about 3.3 minutes at 600 a minute, the enrichment about 33 minutes of ceiling time, and the archive 50 calls to the full history route with twenty in flight. Then verify on your own key. Run each workload small, log every 429 together with its Retry-After, and compare what you observed with what was published. A limit you measured is evidence; a limit you read is a claim. Finally, price each workload on the same sheet, because a provider whose limits fit but whose meter counts resources rather than calls can still lose the comparison on cost.

What data third-party APIs can access

A third-party API reads public data, and that sets the boundary of what any of them can access, whatever its limits. Public posts, profiles, follower and following lists, replies, quotes, lists, communities, Spaces metadata and trends are reachable. Protected accounts are absent by construction, because their posts are not public, and deleted posts are gone from the source, so no provider can return either, and one that claims to deserves suspicion. Private data belongs to an account, so it is reachable only as that account: here the home timeline, bookmarks, likes, direct messages and followers-you-know run through a session the account owner registers, and nothing about one account's session reaches another account's data. Writes work the same way, acting as the account whose session is attached. That boundary interacts with rate limits in one useful way. A public read needs no account context, so any number of public reads can share one key's 600 requests a minute, while private reads are scoped to the account they belong to. A workload mixing the two should still budget them as one pool, because both draw on the same per-key ceiling.

Where to check pricing

Rate limits and prices are often published in different places, and both are worth reading before you size a job. Here the price of every operation is stated in the published OpenAPI reference, one line per endpoint, and the bands are short to list: $0.0008 for a standard call, $0.0016 for the premium writes and direct message reads, $0.0024 for full history and complete reply sets, $0.004 for thread expansion and Grok chat, $0.005 for each account recovery step, $0.01 for a successful login, and 24 routes that cost nothing. Your own spend is visible without spending: account/me returns remaining credits, credits consumed and total requests served, and account/payments lists your payment history, both free. On the official platform the pricing page now lists pay-per-use rates by resource rather than subscription tiers. Read the price and the limit together, because they answer different questions. The limit says how fast you can go; the price says what going that fast costs. A job that fits comfortably inside a rate limit can still be expensive on a per-resource meter, and a cheap meter does not help if the limit stretches the job past its deadline.

What developers and startups actually build

Limits read differently once they are attached to a real product, so here is how common builds sit against 600 requests a minute and 20 in flight. A brand monitor watching fifty accounts uses no read budget at all for detection, because monitors are free and push new posts to a webhook; it spends requests only when it enriches what arrives. A social listening dashboard running twenty saved searches every five minutes makes four requests a minute, under one percent of the ceiling. A lead list built from a keyword sweep, a few hundred search pages plus a batch profile pass at up to 100 accounts per request, finishes in minutes. A reply bot is bounded by writes rather than reads, and by X's automation rules more than by any request limit. A research archive of a few hundred accounts through the full history route is the one build that genuinely fills twenty concurrent slots, because each call is slow and independent of the others. Across all five, the binding constraint is rarely the per-minute number. It is concurrency on archive work and design everywhere else, which is the practical case for one published figure: a team can size the product on its first day without a conversion table.

Enterprise plan versus pay per use

On the official platform, the two remaining ways to buy access differ in how their limits are set as much as in price. Pay-per-use publishes its numbers: per-endpoint request windows, the per-resource rate card, and a cap of 3 million post reads per monthly billing cycle. Enterprise publishes none of them. It is a negotiated contract sized to the workload, reached by crossing the pay-per-use cap, and its ceilings can be raised without the public table changing, which is why the response headers on an enterprise credential are a better guide than the documentation. In plain terms, pay-per-use gives you known limits and a known meter up to a volume line, and Enterprise gives you a negotiation. A per-call API sits on a third path: published limits that do not change by endpoint, no monthly volume cap, and a price per call that is the same on the first request as on the millionth. If you are weighing Enterprise only because your volume crosses 3 million posts a month, price that volume on a per-call meter first. At about 20 posts a call, 3 million posts is 150,000 calls, or $120 here, which tends to settle the question before any meeting is booked.

Legacy Basic and Pro plans

Many rate limit tables still in circulation describe X's legacy plans, so check which plan a number belongs to before you build on it. Basic cost $200 a month and Pro $5,000 a month, each bundling its own fixed monthly allowance. X closed both to new signups in February 2026, and its pricing page now lists no subscriptions at all, so a new integration cannot buy either one and should not size itself against their figures. If your team already holds one of those plans, the honest source for your limits is your own credential: read x-rate-limit-limit, x-rate-limit-remaining and x-rate-limit-reset on live responses rather than a table written for a plan new customers can no longer buy. If you are comparing providers today, compare against pay-per-use, whose rate card and 3 million post monthly cap are current, or against a per-call API whose single figure, 600 requests a minute per key, applies to every endpoint it serves. Blog posts quoting Basic and Pro allowances are history rather than a planning input, and a sizing exercise built on them will be wrong in both directions at once: too generous on volume and too strict on price.

The two narrower caps beside the main ceiling

One figure covers almost everything on this API, and two narrower caps cover the rest, published so nobody has to discover them in production. Direct message sends are capped at 150 an hour per key, enforced as a sliding window rather than a counter that resets on the hour, so a burst at the top of the hour does not earn a fresh allowance a minute later. Attempts count toward that cap rather than successes, which means a run of failing sends spends the same budget as a run of good ones, so fix a failing send before retrying it. Credential logins are capped at 10 an hour. Both caps answer a 429 with Retry-After when exceeded, exactly like the main ceiling, and the refused call is not billed. Both also apply to actions taken as an X account rather than to public reads, which is why they sit so far below the read ceiling. Plan a direct message campaign at no more than 150 sends an hour, which is 3,600 in a day at the very most, and treat a login as a setup step that happens once, not something to repeat at the start of every run of a job.

Retry-After, and why the refused call is free

When a key crosses its ceiling here, the response is a 429 carrying Retry-After, which says how long to wait before the next attempt. Read responses also carry X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset, so a client can slow itself down before it is refused rather than after. Those are the capitalised names rather than X's lowercase x-rate-limit-* set, so a client written against one needs its header lookups adjusted for the other. The refused call itself is not billed. That matters more than it sounds, because it changes the cost of a mistake: a client that retries too eagerly wastes time but not credit, and a backoff bug shows up as latency on a graph rather than as a line on an invoice. The right loop is still the plain one. Read Retry-After, sleep that long with a little jitter, retry once, and if the next attempt is refused as well, back off exponentially. Log every 429 together with its route and the remaining value from the last successful response, since a rising refusal rate is the earliest sign that a workload has outgrown its pacing.

Published rate limit, by endpoint class

Questions and answers

Do rate limits and pricing ever interact?

They interact through your architecture rather than through the billing system. A tight limit forces you to spread work over time, which changes how long a job runs and therefore how long you hold infrastructure, but it does not change the per call price. The trap runs the other way: teams economise on calls to stay inside a limit, cache aggressively, then serve stale data. Decide what freshness the product needs first, then check whether the limit permits it, rather than letting the limit set your freshness silently.

Do rate limits differ between an app token and a user token on X?

Yes, and the difference runs in both directions, which is why the tables carry two columns. Recent search allows 450 per 15 minutes on an app token and 300 on a user token, so the app token is the more generous one there. Post creation allows 10,000 per 24 hours on an app token and 100 per 15 minutes on a user token, which are not comparable at all. Decide which token type a workload uses before you size it, because the same job can be comfortable on one and blocked on the other.

Should I cache to stay inside a rate limit?

Cache because the data does not change, not because a limit is tight. Caching driven by a limit tends to grow stale windows nobody revisits, and the freshness cost stays invisible until somebody notices the product is wrong. Decide what freshness the feature actually needs first, then check whether the limit permits it. If it does not, the honest options are a higher tier, a different provider, or a narrower feature, rather than a quietly staler cache.

Does a uniform limit apply per key or per account?

Per key, which matters when you run several workloads. Two processes sharing one key share one budget of 600 a minute and 20 concurrent, so a batch job can starve a latency-sensitive read path without either of them being individually at fault. If a workload needs predictable pacing, give it its own key rather than reasoning about who else is using yours.

Does a rate limit apply to failed requests too?

Usually yes, which is the detail that turns a retry loop into an outage. A request that returns an error still consumed a slot in the window on most implementations, so a tight retry against a failing endpoint burns budget at the same rate as successful traffic and can keep you saturated indefinitely. That is the mechanism behind the advice to back off on a 429 rather than retry immediately: the retries themselves are what prevent the window from recovering. Treat any retry policy as spending from the same budget as the original call.

Keep reading

• Twitter API rate limits, endpoint by endpoint
• What does rate limited mean on Twitter?
• Twitter API pricing, full comparison
• API documentation