Updated July 6, 2026: re-verified every pay-per-use rate against X's official pricing documentation, added a cost-per-1,000-tweets normalization across the official and flat-rate billing models, and refreshed the free-access options that actually exist for developers in 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. The structural difference is the billing unit: the official API charges for every object in a response, while Sorsa bills one flat rate per request, which works out to a cost from $0.02 per 1,000 tweets on batch endpoints (verified July 2026) and up to 50x cheaper on the read-heavy workloads this guide walks through. Every new Sorsa account also starts with 100 free requests: one-time, no credit card, they never expire, and they cover all 40 endpoints, enough for up to 10,000 tweets of real testing. 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 the gap opens up.
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. The next two sections put hard numbers on that gap, because the billing-unit difference 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 July 6, 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.
How much does the X API cost per 1,000 tweets?
Reading 1,000 tweets on the official X API costs $5.00 in post reads at $0.005 per resource, and pulling the 1,000 author profiles alongside them adds another $10.00 in user reads at $0.010 each. So 1,000 complete tweets with author data cost $15.00 on the official pay-per-use model, before deduplication savings.
Per-1,000 is the honest unit for comparing providers, because different APIs slice billing differently: the official API charges per object, and flat-rate providers charge per request that returns many objects. Normalized that way, the numbers verified in July 2026 look like this:
| Method | What one request returns | Cost per 1,000 tweets |
|---|---|---|
| Official X API post reads | 1 post = 1 billable resource | $5.00 ($15.00 with author profiles) |
| Sorsa batch endpoints | up to 100 tweets, authors included | from $0.02 (Pro plan) |
| Sorsa search endpoints | ~20 tweets, authors included | ~$0.10 (Pro plan) |
The takeaway: on batch retrieval, Sorsa prices 1,000 complete tweets from $0.02, against $15.00 for the same data on the official API. Even on search endpoints, where each request returns about 20 tweets, the normalized cost stays near $0.10 per 1,000.
The two Sorsa rows exist because the per-1,000 figure depends on how many items one request returns. The batch tweet lookup endpoint accepts up to 100 tweet IDs per request, so 1,000 tweets take 10 requests: $0.049 per 1,000 on the $49 Starter plan, $0.02 on Pro, $0.018 on Enterprise. Search-style endpoints return about 20 tweets per request, so the same 1,000 tweets take 50 requests, roughly $0.10 on Pro. Profile data is even denser: follower endpoints return up to 200 profiles per request, which normalizes to from $0.01 per 1,000 profiles, against $10.00 on the official API.
Author data is the quiet multiplier in every one of these comparisons. Official reads bill the author profile separately as a user read; every Sorsa tweet response embeds the full author object at no extra cost, so the per-1,000 figures above already include data that costs twice as much as the tweets themselves on the official side.
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.
Free access to X data does still exist in 2026, just not from X. The practical evaluation ladder runs through third-party providers, and it has three rungs. First, browser tools: the Sorsa API playground runs live endpoints with no key and no signup, enough to validate that the data shape fits your use case. Second, free request allowances: every new Sorsa account gets 100 free requests, one-time, no credit card, they never expire, and they cover all 40 endpoints, which equals up to 10,000 tweets or 20,000 profiles, a real proof-of-concept rather than a taste. For context, the standard free offer across third-party X data providers is a small one-time trial credit, typically around $0.10 to $1, a few hundred to a few thousand records (verified against public pricing pages, July 2026). Third, a paid plan once the workload is proven. Our guide to getting X data without a developer account covers the whole path.
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.
What do real workloads cost on the X API?
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. The same 100,000-post collection that costs $500 in official post reads runs about $2 on Sorsa's Pro plan via batch endpoints, at the from-$0.02-per-1,000-tweets rate, author profiles included. The per-plan pricing breakdown shows how the per-1,000 rate falls from $0.049 on Starter to $0.018 on Enterprise as volume grows.
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.
Within the third-party market itself, per-1,000 pricing varies widely. Pay-as-you-go providers typically publish rates around $0.05 to $0.50 per 1,000 tweets; TwitterAPI.io, for example, lists $0.15 per 1,000 tweets on its public pricing page (verified July 2026). Sorsa's flat plans normalize lower, from $0.02 per 1,000 tweets on batch endpoints, because each request returns up to 100 tweets and the request price falls with plan size:
| Sorsa plan | Monthly price | Requests included | Cost per 1,000 tweets (batch base) |
|---|---|---|---|
| Starter | $49/mo | 10,000 | $0.049 |
| Pro | $199/mo | 100,000 | $0.02 |
| Enterprise | $899/mo | 500,000 | $0.018 |
One request on these batch endpoints returns up to 100 tweets, and follower endpoints return up to 200 profiles, which is what makes the per-1,000 figures possible. Here is the head-to-head against the official model on the read operations that dominate data work:
| Official X API (pay-per-use) | Sorsa API | |
|---|---|---|
| Pricing model | Per resource fetched | Per request (flat) |
| Cost per 1,000 tweets | $5.00 | from $0.02 (batch base) |
| Cost per 1,000 profiles | $10.00 | from $0.01 (batch base) |
| Free start | None; credits required before any call | 100 free requests (up to 10,000 tweets), no card |
| 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: the official API charges $5.00 per 1,000 post reads plus $10.00 for the author profiles, while Sorsa's batch base delivers the same 1,000 complete tweets from $0.02. That is where the up-to-50x cost difference on read-heavy work comes from, and table-level math on batch endpoints runs even wider.
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, and a single API key with no OAuth dance and no approval queue. 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 posting, DMs, and engagement automation stay on the official API, which is the compliant path for write actions. And if you want zero monthly commitment for a tiny one-off job, a pay-as-you-go provider or the official API's no-minimum model can fit better than a flat plan; our comparison of Twitter/X API alternatives covers the wider field with real numbers. The decision compresses to this:
Write actions (posting, DMs): the official X API, the only compliant path for writing to the platform.
Under ~10,000 reads a month: official pay-per-use; no monthly minimum makes tiny volume genuinely cheap.
Occasional one-off scrapes: a pay-as-you-go third party; no commitment, per-call billing fits sporadic use.
Read-heavy production workloads: Sorsa; flat per-request billing from $0.02 per 1,000 tweets, author profiles included.
Above 2M post reads a month with compliance needs: an X Enterprise contract, historically from ~$42,000/mo.
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. Their read spend dropped from thousands of dollars a month to under $200 on the Pro plan, a cut of more than 90 percent, with author profiles bundled in instead of billed separately. That hybrid split (reads on a flat-rate provider, writes on the official API) is the most common outcome we see, and the endpoint-by-endpoint migration guide walks through it.
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 Starter to Pro drops the batch-base cost from $0.049 to $0.02 per 1,000 tweets, so once your usage regularly outgrows the 10,000-request Starter quota, the Pro plan cuts the per-request price by more than half.
FAQ
Is there a free X (Twitter) API in 2026?
There is no free X (Twitter) API from X itself in 2026. Pay-per-use replaced the free tier in February 2026, and new accounts must buy credits before making any call. Free access survives only through third parties: Sorsa, for example, gives every new account 100 free requests covering up to 10,000 tweets, one-time, with no credit card.
How much does the X API cost per 1,000 tweets?
Reading 1,000 tweets on the official X API costs about $5.00 in post reads, plus $10.00 more if you expand the 1,000 author profiles. Flat-rate billing changes the unit: on Sorsa's Pro plan, batch endpoints price 1,000 tweets at $0.02 (10 requests of 100 tweets), while search endpoints work out to roughly $0.10 per 1,000, author profiles included either way.
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.
Does the X API offer any discounts or credits back?
The X API offers two built-in cost offsets in 2026. A 24-hour deduplication window charges repeated fetches of the same resource only once per UTC day. And cumulative spend earns xAI (Grok) API credits, from 10% back above $200 up to 20% back above $1,000 per billing cycle, usable on xAI's API rather than on X API calls themselves.
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, normalizing to from $0.02 per 1,000 tweets.
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, and that costs nothing. Try the exact endpoints you need in the browser playground with no signup, then create an account and run a real proof-of-concept on the 100 free requests every new account gets: no credit card, they never expire, and they stretch to 10,000 tweets or 20,000 profiles across all 40 endpoints. From there, plans start at $49/month with batch-endpoint costs from $0.02 per 1,000 tweets on Pro, every tier gets the same flat 20 requests per second, and the quickstart has you pulling live data in about three minutes with a single API key. 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 math described here is something we re-cost against our own pipelines whenever X changes its rates. The official figures were re-verified on July 6, 2026 against X's pay-per-use pricing documentation and the developer-platform announcements covering the pay-per-use launch, the April 20 rate restructuring, and the legacy Basic deprecation; third-party per-1,000 rates were checked the same day against those providers' public pricing pages, and our own numbers come from our published pricing. Questions or a correction? Reach us via About or contacts@sorsa.io.