What the X API Actually Costs in 2026 — and How to Work Out Your Own Number
What the X API Actually Costs in 2026 — and How to Work Out Your Own Number
Most pages about X API pricing are out of date. They quote a $100/month Basic tier that no longer takes new signups, or a free tier with limits that were revised more than once since.
Here's the current state, and — more usefully — how to calculate what your specific use case would cost before you commit to anything. The pricing page gives you rates. It doesn't tell you how many calls your idea actually needs, and that's the number that decides whether a project is viable.
Current tiers
As of early 2026, the structure changed shape: new developers go to pay-per-use rather than picking a monthly tier.
| What you get | Cost | |
|---|---|---|
| Free | Write-focused, minimal reads | $0 |
| Pay-per-use | Read access, metered | $0.005 per post read, up to 2M reads/month |
| Enterprise | Full-archive search, high volume, support | From ~$42,000/month |
The older $200/month Basic and $5,000/month Pro tiers still exist for accounts already on them but are closed to new signups.
⚠️ The free tier is not a reading tier. This catches people out constantly. It's oriented around posting, not retrieving — so "I'll prototype on free and upgrade later" often fails at step one, because the read call you need isn't available at all rather than merely limited.
★The important shift: cost now scales with how much data you read, not with which box you ticked.★ That's better for small projects and considerably worse for anything that reads broadly.
Working out your own number
Rates are the easy half. The half that surprises people is call volume, because it's driven by things that feel free when you're sketching the design.
The formula:
posts read per month × $0.005 = your bill
Now the part people get wrong — estimating the left side.
Monitoring an account. Checking one account every 5 minutes is 8,640 checks a month. If each returns 20 posts, that's 172,800 posts read — about $864/month for one account. Check every minute instead and it's five times that.
⚠️ You pay for posts read, not new posts found. Poll every 5 minutes and most checks return the same posts you already have. On a quiet account, upwards of 95% of what you're paying for is data you already had. The polling interval, not the account's activity, sets the bill.
Backfilling history. Pulling 100,000 historical posts is a flat $500 — and full-archive search, which is what you need to reach genuinely far back, requires Enterprise. Many "let's analyse the last two years" projects die at exactly this line.
Follower lists. Large accounts page in chunks. A 500,000-follower account is many calls, and if you're diffing daily to detect unfollows, you're re-reading the whole list every time. The set-difference approach is what makes that tractable, but it doesn't change how much you must read.
Search. Cost scales with results returned, so a broad query is expensive in a way a narrow one isn't. This is where precise operators turn into a budget item rather than a nicety — min_faves: on a busy term can cut what you read by an order of magnitude.
The three mistakes
Across the estimates people get wrong, the same three account for nearly all of it.
1. Estimating from new content instead of read content. "The account posts 5 times a day, so ~150 posts a month." No — you'll read thousands, because every poll returns the recent window regardless of what's new. Estimate polls × posts-per-response.
2. Forgetting the retry path. A timeout that you retry has been paid for twice. Under normal conditions this is noise; during an upstream incident it can be a large multiple. Any estimate assuming a 100% success rate is optimistic by whatever your real failure rate turns out to be.
3. Not accounting for development. Building against a metered API means every test run costs money. Teams routinely spend a meaningful fraction of month one's budget on debugging — and the tighter the loop, the worse it is. Budget for it or cache aggressively in development.
When each option makes sense
Being straight about this, including where we're the wrong answer.
Official API is right when: you need write access (posting, replying — nobody else can offer that), you need official sanction for compliance or publication, or you need full-archive search and have Enterprise budget.
A managed data API is right when: you're reading public data at a volume where per-post pricing hurts, and you'd rather not maintain the extraction yourself. That's our case — flat per-call pricing rather than per-post, which is the difference that matters when a single call returns a hundred posts.
Building it yourself is right when: volume is small, it's a one-off, or you have a genuinely unusual requirement. The full comparison covers what that costs in maintenance.
⚠️ One thing to be clear about: we are read-only. If your project needs to post, reply, or follow, the official API is the answer and nothing here substitutes for it.
Comparing like with like
The trap when comparing any two providers is that the units differ. Per-post and per-call are not comparable numbers, and a per-call price looks higher until you divide by how many posts a call returns.
Three questions that make comparisons honest:
- What's the unit? Per post, per call, per row, per month? A call returning 100 posts at a flat rate is 100× cheaper per post than it looks.
- What happens on failures? Some providers bill for errors and empty results. Worth checking, and worth testing rather than trusting the docs — send a deliberately malformed request and watch the balance.
- What's excluded? Rate limits you have to manage, retries you have to pay for, and volume commitments all change the effective price.
For what it's worth, our own rule is that we bill when a lookup actually ran — including when it ran and found nothing, because the work happened. We don't bill for requests we reject before dispatch, or for errors on our side. You can verify both in a couple of minutes.
Questions people ask
How much does the Twitter API cost? Pay-per-use at $0.005 per post read, up to 2M reads/month. Enterprise from around $42,000/month. The old $200 Basic and $5,000 Pro tiers are closed to new signups.
Is the X API free? There's a free tier, but it's write-oriented with minimal read access. For most data projects it isn't usable.
How do I get an X API key? Apply through the developer portal, describe your use case, and wait for approval. Timelines vary.
What is the X API rate limit? Limits vary substantially by endpoint and tier. Handling them correctly matters more than knowing the exact numbers, which change.
Why did Twitter API pricing change? X restructured API access in 2023 and has revised it several times since. The 2026 change moved new developers from monthly tiers to metered pricing.
What happened to the free Twitter API? It still exists but is far narrower than pre-2023 — write-focused rather than the broad read access it used to allow.
Can I still use the Basic tier? Existing accounts keep it. New signups go to pay-per-use.
How much is 1 million tweets? At $0.005 per post read, $5,000 — plus Enterprise if reaching them requires full-archive search.
Is there a cheaper alternative? For read-only public data, third-party APIs generally price lower per post. For writing, there's no alternative — the official API is the only route.
What's the difference between v1.1 and v2? Different generations with different endpoints and response shapes. v2 is current for new work; some v1.1 endpoints remain in use.
Do I need Enterprise for historical data? For full-archive search, yes. Recent history is reachable without it.
How do I estimate my API costs? Multiply polls per month by posts returned per poll, then by the per-post rate. Estimate from what you'll read, not from what's new.
Does the API charge for failed requests? Depends on the provider and the failure. Worth testing directly rather than assuming — a malformed request and a balance check takes two minutes.
Can I get a refund for unused credits? Policies vary by provider. Check before prepaying a large amount.
Is the X API worth it? If you need write access or official sanction, there's no substitute. If you're reading public data, run the arithmetic above first — it frequently comes out unfavourable at volume.
What can I do with a free API key? Mostly posting on behalf of an authenticated account. Not a reading tool.
How many requests per month do I get? Pay-per-use caps at 2M post reads monthly. Beyond that is Enterprise.
Do third-party APIs violate X's terms? Reading public data is broadly practised. Automating actions on accounts is the genuinely risky category — see the compliance section here.
Can I resell X data? Redistribution is restricted under X's terms regardless of how you obtained it. If that's your model, get legal advice specific to your case.
What's the cheapest way to monitor a few accounts? Poll at the slowest interval your use case tolerates. Moving from 1-minute to 5-minute checks cuts the bill by 80% and, for most purposes, changes nothing that matters.
How do I reduce API costs? Poll less often, narrow your queries so you read fewer irrelevant posts, cache aggressively during development, and don't re-read data you already have.
How do I create a Twitter developer account? Apply through the developer portal with a description of your use case, then wait for approval. The developer account is free; the API access it grants is what's metered.
What's the difference between Twitter API v2 and v1.1? Different generations with different endpoints and response shapes. v2 is current for new work.
Is there a Python Twitter API library? Several, both for the official API and for third-party ones. Any of them is a wrapper over HTTP calls — see the build-versus-buy comparison.
Is there a Twitter trends API? Trends come from a regional endpoint — see how the trends system works.
How much does the Twitter API cost? ★Tiers change, so verify before budgeting★ — the structural point is that read access above the free tier is metered per post.
Is there a free Twitter API? A free tier exists and is write-oriented — ★read access on it is minimal enough that most read use cases do not fit★.
What is the basic plan? A low-volume paid tier. ★Check the current post cap against your actual volume before committing.★
What does enterprise pricing look like? Negotiated rather than published. ★If pricing is not on a page, it is a sales conversation.★
Why is Twitter API pricing confusing? ★Because read volume, write volume, and endpoint access are priced separately★ — one number never describes it.
How do I estimate my cost? Count posts retrieved, not requests made — ★per-post metering is what most estimates get wrong★.
Is a third-party API cheaper? ★Depends entirely on volume shape.★ Flat per-call pricing suits bursty reads; per-post metering suits steady low volume.
What is the cheapest way to read public data? ★Batch and cache★ — batching cuts volume more than any tier change.
Do I pay for empty results? Depends on the provider. ★Ask whether a lookup that found nothing is billed★ — the honest answer is that the work still happened.
Does the API price include historical data? Rarely — ★archive depth is usually a separate, higher tier★.
Can I test before paying? Most providers offer a trial or free calls. ★Test with your real query shape, not a sample one.★
What hidden cost catches people out? ★Retries.★ A tight retry loop on errors multiplies spend without producing data.
The short version
If you're writing to X, use the official API — nothing else can do it.
If you're reading public data, do the arithmetic before you build. The rate is simple; the call volume is where estimates go wrong, and it's almost always higher than the first guess because polling re-reads what you already have.
Our API prices per call rather than per post, which is the distinction that matters when one call returns a hundred posts. Read-only, no rate limit of your own to manage, and nothing billed for requests we reject before dispatch or errors on our side.
Related reading: comparing every way to get X data · what to do when you hit rate limits · monitoring accounts without over-polling.