Updated June 14, 2026: X has begun auto-migrating all remaining legacy Basic subscribers to pay-per-use, a change that took effect June 1, 2026. We re-verified every per-resource rate below, plus the Basic migration, against X's official pricing documentation and developer announcements on June 14, 2026.
Key Takeaway: The X (Twitter) API uses pay-per-use pricing in 2026, not subscriptions. Developers pay per resource: $0.005 per post read, $0.010 per user read, $0.015 per post created, and $0.20 if it contains a URL. There is no general free tier, and post reads are capped at 2 million per month.
If you have been pricing this out and the numbers feel slippery, that is because X changed the model twice in four months: pay-per-use replaced subscriptions in February 2026, then per-endpoint rates and access were restructured again on April 20. We build Sorsa API, an alternative Twitter/X API provider, and re-cost our own pipelines against every one of these changes. For read-heavy work the gap is not subtle: because Sorsa bills one flat rate per request instead of per resource, and runs a flat 20 requests per second on every plan, it comes out up to 50x cheaper than the official API on the workloads this guide walks through, with a single API key and no approval queue. Below we lay out exactly what the official API charges in 2026, what happened to the old Basic and Pro plans, whether any free access survives, and where that gap opens up.
Table of Contents
- How X API pricing works in 2026
- X API pay-per-use costs by operation
- What happened to the Basic, Pro, and Enterprise tiers?
- Is there still a free X (Twitter) API tier in 2026?
- What X changed on April 20, 2026
- How much does the X API cost for real workloads?
- When the official X API is the right choice
- When a third-party Twitter/X API costs less
- How to reduce your X API costs
- FAQ
How X API pricing works in 2026
The X (Twitter) API is billed on a pay-per-use model in 2026: there are no monthly subscriptions for new developers, and you buy credits in advance that are deducted as you call the API. Reads are charged per resource returned, writes are charged per request, and rates differ by endpoint. A search that returns 20 posts is billed as 20 post reads, not one call.
That last sentence is the whole story of why volume gets expensive, so it is worth slowing down on.
You purchase credits through the official X Developer Console, and the balance drops in real time as requests succeed. When the balance hits zero, requests are blocked until you top up. X added auto-recharge, per-cycle spending limits, and a usage endpoint so you can watch consumption programmatically, all of which help you avoid surprise overruns but none of which change the underlying per-resource math.
Two billing units sit side by side. Reads bill per resource: every post, profile, or follower object in a response is a separate billable unit. Writes and actions bill per request: creating a post is one charge regardless of length. The split matters because read-heavy work (search, monitoring, follower analysis, dataset building) scales with the number of objects you pull, while write-heavy work (posting, DMs) scales with the number of actions you take.
There are two cost cushions built in. First, a 24-hour deduplication window: fetching the same resource more than once within a single UTC day is charged only on the first request, resetting at midnight UTC. X calls this a soft guarantee, since outages can occasionally break it. Second, X bundles xAI (Grok) API credits with API spend, scaling from 0% under $200 of cumulative spend up to 20% back above $1,000. A 20% kickback on a $1,000 bill still leaves $800 of net spend, so treat it as a perk for teams already building on Grok, not a reason to spend more.
This per-resource design is exactly where flat-rate alternatives diverge. A flat-rate provider like Sorsa charges one unit per request no matter how many items come back, and embeds the full author profile inside every tweet response at no extra charge. We will put hard numbers on that gap further down, but flag the model difference now because it accounts for most of the price spread between the official API and third-party providers.
X API pay-per-use costs by operation
Here are the official X API per-unit costs in 2026, current as of the April 20, 2026 update and re-verified on June 4, 2026. Read operations are billed per resource returned; create operations are billed per request.
| Resource | Unit cost | Charged per |
|---|---|---|
| Posts: Read | $0.005 | resource fetched |
| Users: Read | $0.010 | resource fetched |
| Following / Followers: Read | $0.010 | resource fetched |
| DM Events: Read | $0.010 | resource fetched |
| Owned Reads (your own posts, bookmarks, followers, likes, lists) | $0.001 | resource fetched |
| Lists: Read | $0.005 | resource fetched |
| Spaces: Read | $0.005 | resource fetched |
| Communities: Read | $0.005 | resource fetched |
| Analytics: Read | $0.005 | resource fetched |
| Trends: Read | $0.010 | resource fetched |
| Media: Read | $0.005 | resource fetched |
| Content: Create (post without URL) | $0.015 | request |
| Content: Create (post with URL) | $0.20 | request |
| Content: Create (URL in summon reply) | $0.01 | request |
| DM Interaction: Create | $0.015 | request |
| User Interaction: Follow / Like / Quote-post | Enterprise only | removed from self-serve |
A few patterns are worth pulling out. Core resource reads (posts, lists, spaces, communities, media, analytics) cluster at $0.005. Anything tied to a user (profiles, followers, following, DM events, trends) costs $0.010. Owned reads, where your app pulls its own authenticated account's data, are the cheapest at $0.001. Writes now split sharply on one factor: a plain post is $0.015, but the moment it contains a link it becomes $0.20, a more than tenfold jump on the same action.
The Developer Console is the source of truth for live rates, since X has said per-endpoint pricing can vary by operation and data scope. If you see a pricing screenshot floating around a forum, treat it as possibly stale and confirm in-console.
What happened to the Basic, Pro, and Enterprise tiers?
The fixed Basic and Pro subscription tiers are legacy in 2026 and closed to new developers. X replaced subscriptions with pay-per-use in February 2026, and on June 1, 2026 it began auto-migrating all remaining legacy Basic subscribers (both monthly and annual) to the pay-per-use plan. New signups can only choose pay-per-use or Enterprise.
If you are reading an older guide that presents X API pricing as a clean Free / Basic / Pro / Enterprise ladder, that framing is out of date. Here is what each plan was and where it stands now:
| Legacy plan | What it cost | Status in 2026 |
|---|---|---|
| Free | $0 (write-limited stub) | Discontinued for new users; legacy free users migrated to pay-per-use with a one-time $10 credit voucher |
| Basic | $200/month | Deprecated; all Basic subscribers auto-migrated to pay-per-use starting June 1, 2026 |
| Pro | $5,000/month | Legacy only; closed to new signups, migration direction signaled but not yet forced |
| Enterprise | ~$42,000+/month | Still available; the only route past the 2M post-read cap, negotiated with X sales |
The migration is not just a price relabel. Under the old $200 Basic plan a developer paid a flat fee for a fixed bucket of actions (historically up to tens of thousands of posts and reads). Under pay-per-use, a hobby project that posts a few times a week can drop to single-dollar bills, while an app that used to max out Basic can easily land north of $500/month at metered rates. X confirmed the legacy Basic deprecation in an official X Developers announcement, and prorated value on annual plans is converted to pay-per-use credits at migration.
For the wider context on how Twitter API access went from free to this, see our breakdown of why the Twitter API got so expensive.
Is there still a free X (Twitter) API tier in 2026?
There is no general free X (Twitter) API tier in 2026 for new developers. The old free tier was discontinued when pay-per-use launched in February 2026, and new accounts must purchase credits before making any call. The only surviving free access is a narrow, approval-gated program for designated public-utility apps, granted by X on a case-by-case basis.
So the honest answer depends on who is asking, which our guide on whether the X API has a free tier breaks down case by case.
If you are a new developer, you start at pay-per-use with no free allowance: zero credits means blocked requests. If you ran a legacy free-tier app that was recently active, X migrated you to pay-per-use with a one-time $10 voucher, per its pay-per-use launch announcement, which covers roughly 2,000 post reads before it runs out. If you operate a genuine public-good service, you can apply for free access, but approval is selective and not something to plan a product around.
For testing or low-volume data collection without committing credits, the practical free options are third-party providers that offer free trials or playgrounds. Our own API playground lets you run live endpoints in the browser with no key and no signup, which is enough to validate that the data shape fits your use case before anyone pays for anything.
What X changed on April 20, 2026
X announced a second pricing overhaul on April 16, 2026 that took effect on April 20. It made three rate changes and one access removal, and it reshaped costs most for anyone publishing links or automating engagement.
The four shifts, in plain terms:
- Owned Reads dropped to $0.001 per resource across 12 endpoints that return your own data (bookmarks, blocking, muting, pinned lists, owned lists, list memberships, followed lists, reverse-chronological timeline, your tweets, your mentions, your liked tweets, your followers). That is a 5x to 10x cut, but only when you pull your own authenticated account's data, not third-party accounts on the same endpoint paths.
- Standard post creation rose from $0.010 to $0.015 per request, a 50% bump on every plain post.
- Posts containing a URL jumped to $0.20 per request, a roughly 1,900% increase. URLs inside summon replies are exempt and stay at $0.01.
- Follow, like, and quote-post write endpoints were removed from all self-serve tiers. Engagement automation is now Enterprise-only, with no grace period beyond the four-day announcement window.
The owned-reads cut is the one piece of good news for publishers managing their own accounts. Everything else tightened the screws: link publishing at volume became expensive, and programmatic engagement effectively left the reach of self-serve developers. This is the most aggressive restructuring since the 2023 paywall, and it landed barely two months after pay-per-use went live.
None of this happens in a vacuum. Social platforms now treat data access as a revenue line, not a courtesy: Reddit, for one, signed a $60 million annual AI-data licensing deal with Google. X's pricing reflects the same shift toward monetizing every read and write.
How much does the X API cost for real workloads?
For real workloads, official X API cost scales with data volume because reads bill per resource. Reading 10,000 posts costs $50, 100,000 posts costs $500, and 1,000,000 posts costs $5,000. User and follower reads cost twice as much per item, at $0.010 each. Write costs depend on links: 1,000 plain posts cost $15, while 1,000 posts with URLs cost $200.
Mapped to common projects, the math looks like this:
| Workload | Official X API math | Estimated cost |
|---|---|---|
| 10,000 post reads | 10,000 x $0.005 | $50 |
| 100,000 post reads | 100,000 x $0.005 | $500 |
| 1,000,000 post reads | 1,000,000 x $0.005 | $5,000 |
| 10,000 user profile reads | 10,000 x $0.010 | $100 |
| 100,000 follower/following reads | 100,000 x $0.010 | $1,000 |
| 1,000 standard posts | 1,000 x $0.015 | $15 |
| 1,000 URL posts | 1,000 x $0.20 | $200 |
The detail that wrecks read-heavy budgets is that author data bills separately. A search call returning 20 posts is 20 post reads ($0.10), and if you also expand the author profiles it is another 20 user reads ($0.20), so one search call costs $0.30. Scale that to a continuous monitoring workflow polling around the clock and you brush against the 2-million-post cap, where the only exit is an Enterprise contract.
A flat-rate provider changes the unit. On Sorsa's Pro plan the same 20-post search call is one request at $0.00199, with all 20 author profiles included. Our batch tweet lookup endpoint takes up to 100 tweet IDs in a single request: one request, $0.00199, 100 complete tweets with author data. The equivalent on the official API is 100 post reads ($0.50) plus 100 user reads ($1.00), or $1.50 for the same data. The full plan-by-plan breakdown lives on the Sorsa API pricing page.
When the official X API is the right choice
The official X API is the right choice when you need to write to the platform or access data only X can provide. Posting, sending DMs, the Ads API, official compliance and firehose agreements, and filtered streaming all require the first-party API. At very low read volume, under roughly 10,000 post reads per month, pay-per-use is also genuinely cheap and not worth replacing.
Put bluntly: if your job is to publish your own content, run a posting bot, or stay compliant with a data agreement, you stay on the official API. There is no read-only alternative for write actions, and that is by design. If that describes you and you have not set up access yet, our step-by-step guide to getting an X API key walks through the Developer Console flow.
The friction shows up the moment your work is read-heavy. Search, mention tracking, competitor monitoring, follower analysis, sentiment pipelines, and dataset building all multiply per-resource charges fast, and the 2-million-post cap puts a hard ceiling on continuous monitoring that did not exist on the old Pro plan.
When a third-party Twitter/X API costs less
A third-party Twitter/X API costs less than the official API once your read volume crosses roughly 10,000 post reads per month. Below that, pay-per-use is cheap enough not to bother. Above it, flat per-request pricing pulls ahead quickly, because one request returns many billable objects for a single unit instead of charging for each one.
Here is the head-to-head on the read operations that dominate data work, with real numbers for both sides:
| Official X API (pay-per-use) | Sorsa API | |
|---|---|---|
| Pricing model | Per resource fetched | Per request (flat) |
| Cost: 1,000 post reads | $5.00 | ~$0.10 (50 requests at $0.00199, Pro) |
| Cost: 1,000 user profiles | $10.00 | ~$0.01 (5 requests via followers endpoint, Pro) |
| Monthly cap | 2M post reads | Plan-based (10K to 500K requests) |
| Auth | OAuth 2.0 + Bearer Token | Single API key header |
| Write access | Posting and DMs (engagement is Enterprise-only) | None (read-only) |
| Batch endpoints | Limited | Up to 100 tweets or profiles per request |
| Author profile in tweet response | Billed separately as a user read | Included free |
The gap is structural, not a temporary discount. Collecting 100,000 tweets costs $500 in post reads on the official API; on Sorsa's Pro plan, 5,000 requests of about 20 tweets each cover the same volume for roughly $10, with author profiles bundled in, data that would add another $1,000 on the official side. That is where the up-to-50x cost difference on read-heavy work comes from.
Sorsa is built for exactly this case: a read-only Twitter/X API with 40 endpoints across 8 categories, spanning profiles, tweets, search, followers, lists, communities, and verification data, a flat 20 requests per second on every plan, a single API key with no OAuth dance and no approval queue, and full tweet objects that embed the author profile for free. We have served over 5 billion requests since 2022, and the model is deliberately boring: predictable monthly bills, no per-resource math, no URL-post premium, no 2-million cap.
To be fair about the tradeoffs: Sorsa is read-only, so if you need to post, send DMs, or automate engagement, you still keep a minimal official API setup for those write actions. And if all you want is the single absolute-cheapest endpoint for one narrow task, you can always shop around the broader market; if you want dependable, complete read access at a flat price, that is what we built. For a wider look at the field, see our comparison of Twitter/X API alternatives.
In practice: a 10-person analytics team
We see one migration pattern constantly. A roughly 10-person social analytics team was running mention tracking, competitor monitoring, and follower analysis on the official Pro plan, watching read charges pile up against the 2-million cap. They moved every read operation to Sorsa and kept a thin official API setup purely for posting alerts to their own company account. Because it is around 50x cheaper on post reads and bundles author profiles for free, their read spend dropped from thousands of dollars a month to under $200 on the Pro plan, while write actions stayed where they have to live, on the official API. That hybrid split (reads on a flat-rate provider, writes on the official API) is the most common outcome we see, and the migration guide walks through it endpoint by endpoint.
How to reduce your X API costs
These tactics lower spend on any provider, official or third-party, and our docs on optimizing API usage cover the batching and caching patterns in more depth.
Cache aggressively. The official API's 24-hour deduplication helps, but caching on your end kills redundant calls outright. Store post data with a 6 to 12 hour TTL, and profiles for 24 hours since they change rarely.
Batch every chance you get. If an endpoint takes multiple IDs, use it. Fetching 100 tweets one at a time costs about 100x more than one batch call on any provider.
Use field selection on the official API. The tweet.fields and user.fields parameters trim responses to what you need. The per-resource charge stays, but you waste less bandwidth and processing.
Poll less, stream or list-monitor more. Checking 50 accounts individually every minute costs 50x more than monitoring them through one list. On the official API, use filtered streaming; on a flat-rate provider, watch a single list. See our guides on real-time monitoring patterns and our Twitter API Python guide for working implementations of both.
Right-size your plan. On pay-per-use, keep spending limits tight during development. On flat-rate plans, compare cost-per-request across tiers: moving from Sorsa's $49/month Starter to the $199/month Pro plan drops the per-request cost from $0.0049 to $0.00199, so consistent use above about 8,000 requests already pays for the upgrade.
FAQ
Is there a free X (Twitter) API in 2026?
There is no general free X (Twitter) API in 2026 for new developers. Pay-per-use replaced the free tier in February 2026, and new accounts must buy credits before making any call. Limited free access survives only for approved public-utility apps on a case-by-case basis, and legacy free-tier users were migrated to pay-per-use with a one-time $10 voucher.
How much does the X API cost per 1,000 tweets?
Reading 1,000 tweets on the official X API costs about $5.00, since post reads are billed at $0.005 per resource. Expanding the author profiles adds 1,000 user reads at $0.010 each, another $10.00. Flat-rate providers change this: on Sorsa's Pro plan, 1,000 tweets cost roughly $0.10 across about 50 requests, with author profiles included at no extra charge.
Can you still buy the $200 Basic or $5,000 Pro plan?
No new developer can buy the $200 Basic or $5,000 Pro plan in 2026. Both are legacy subscriptions closed to new signups, and X began auto-migrating remaining Basic subscribers to pay-per-use on June 1, 2026. New accounts choose between pay-per-use and Enterprise, while existing legacy subscribers can stay or opt into pay-per-use.
What happens when you hit the 2 million post reads cap?
Hitting the 2-million post-read cap blocks all post-read endpoints until the next billing cycle. Other endpoint types like user reads and content creation keep working, since the cap applies only to post reads. The only way past it is an Enterprise contract negotiated with X sales, which is selective and historically starts around $42,000/month. For per-endpoint limits separate from this billing cap, see our X API rate limits guide.
Why did the Twitter/X API become so expensive?
The Twitter/X API became expensive for three converging reasons. The 2022 acquisition was heavily debt-financed and X needed new revenue. AI companies were consuming social data for model training at scale, making that data commercially valuable. And aggressive pricing doubled as access control against spam bots and scrapers. The 2026 pay-per-use shift extends this by charging for every individual read and write.
Is there an X API alternative with higher rate limits and simpler auth?
Yes. Third-party providers like Sorsa API offer an alternative Twitter/X API with a flat 20 requests per second on every plan and a single API key header instead of OAuth 2.0. It is read-only and covers 40 endpoints across users, tweets, search, and follower data, with batch endpoints returning up to 100 tweets or profiles per request, making read-heavy work substantially cheaper than the official per-resource model.
Getting started
If official X API pricing is making your search, monitoring, or analytics workflow expensive, the fastest way to settle it is to cost a flat-rate model against your real volume. Run the exact endpoints you need in the Sorsa API playground with no key and no signup, then compare the per-request cost on the pricing page against your expected official-API bill. Plans start at $49/month for 10,000 requests, every tier gets the same flat 20 requests per second, and setup takes about three minutes with a single API key and no approval queue: the quickstart has you pulling live data in a few lines. Keep the official API only for the write actions that genuinely need it.
Reviewed by Keksich, founder of Sorsa, marketer and X API researcher.
How we put this together: we build and operate Sorsa, an alternative Twitter/X API in production since 2022, so the per-resource pain described here is something we re-cost against our own pipelines whenever X changes its rates. The official numbers in this guide were verified on June 14, 2026 against X's official API pricing documentation and its developer-platform announcements covering the pay-per-use launch and the legacy Basic deprecation; our own prices come from our published pricing. Questions or a correction? Reach us via About or contacts@sorsa.io.