X API Cost in 2026: Every Tier and Alternative on One Sheet

The official X API charges $0.005 per post returned, which is $5.00 per 1,000 tweets read, plus $0.010 per user lookup. Third-party read APIs publish rates between $0.75 and $0.04 per 1,000 tweets on their own price pages, ours included, each read from that vendor's own live pricing page on 2026-09-09 and listed with its link in the normalized table below, against the official rates on X's own price sheet. That is a 125x spread across one market, and no page currently states it in a single unit. This one does.

TL;DR

X replaced its fixed plans with credit-based pay-per-use, so the question stopped being which tier and became how many resources. Reads bill per item returned at $0.005 a post and $0.010 a profile, capped at 3 million post reads a month. Writes bill per request, and a post carrying a link is $0.200 against $0.015 for a plain one. Every third-party read API is cheaper per tweet than the official rate. The full rate card for this property sits on the X API pricing page, and this post is the comparison against everything else.

Why this post exists, and what it does differently

Every page currently ranking for X API pricing quotes each vendor in that vendor's own unit. One says $0.005 per resource on its price sheet, another says $0.15 per 1,000 tweets, a third says $0.40 per 1,000 results, and a fourth says $0.75 per record. Each of those four figures comes from that vendor's own published price page, linked in the normalized table below, and the official column comes from X's price sheet. Those are four different things. A reader cannot compare them without doing conversion arithmetic that nobody publishes.

We call the fix the TwitterAPIs Normalized Price Sheet: every provider restated in exactly two units, dollars per 1,000 tweets read and dollars per 1,000 posts written, with the billing unit named beside each rate so the conversion is auditable rather than asserted. That is the definition we will reuse across this cluster, and it is the reason this post is longer than a rate card.

The second thing this post does is produce a number. A worked monthly bill for one named workload, run across every provider, with the arithmetic shown. The competitor page that comes closest has an entire section headed "how to estimate your monthly API cost" and never produces a figure.

The third is honesty about our own worst case. Our list rate assumes a full 20-tweet page. Real pages are not always full. We publish the sparser delivered range on our own pricing page and we use that range, not the list rate, in every worked example below.

How much does the X API cost per 1,000 tweets in 2026?

$5.00. X bills reads per resource returned rather than per request, and a post resource is $0.005 on its published pay-per-usage price sheet as of 2026-09-09. A user resource is $0.010, so 1,000 profile lookups is $10.00. Reads of your own account data, which X groups as Owned Reads across twelve endpoints, are $0.001 per resource.

The per-resource model is the single most important thing to understand, because it changes what a "call" costs. A search request that returns 100 posts bills 100 times. A search request that returns 3 posts bills 3 times. Your invoice tracks the shape of your data, not the shape of your code.

That is also what resolves a complaint that circulated widely. Jon Yongfook, founder of the image-automation SaaS Bannerbear, posted to 16,695 views on 6 July 2026: "Had to fix something because the Twitter API switched to Pay As You Go. Is anyone else using this for production? Pricing seems a little off... 25 cents for 2 requests? This is just for a basic post search."

At $0.005 a post resource, 25 cents is exactly 50 post resources, so two search requests returning 25 posts each produce precisely that bill. The rate card is not wrong and neither is Yongfook. The unit is the thing nobody stated, and this is what the confusion looks like on a production system rather than in a comparison table.

Full official rate card, read from X's own pricing documentation rather than from any summary:

The official X API rate card, read from X's own pricing page

Operation	Unit	Rate	Per 1,000	Source
Posts: Read	Per resource returned	$0.005	$5.00	published
User: Read	Per resource returned	$0.010	$10.00	published
Following/Followers: Read	Per resource returned	$0.010	$10.00	published
DM Event: Read	Per resource returned	$0.010	$10.00	published
Like, Mute, Block: Read	Per resource returned	$0.001	$1.00	published
Owned Reads, 12 endpoints	Per resource returned	$0.001	$1.00	published
Post: Create	Per request	$0.015	$15.00	published
Post: Create (with URL)	Per request	$0.200	$200.00	published
Counts: All	Per request	$0.010	$10.00	published
Trends	Per request	$0.010	$10.00	published

as of 2026-09-09

The three rates that dominate almost every real bill are the post read at $0.005, the user read at $0.010, and the plain post write at $0.015. If you are sizing a project on a napkin, those three numbers plus your subject counts will land within a few percent of the truth. For a per-workload breakdown of how the call graph changes that estimate, the Twitter API cost by workload analysis walks four common shapes.

What replaced the $200 per month Basic tier after X moved to pay-per-use?

Nothing replaced it as a plan. X sells credits and deducts them per resource, so there is no monthly floor to clear before the first call, and no tier to be on. The word tier still appears in search queries constantly, but it no longer describes anything in the product.

X announced the change itself in a post from its own developer account on 6 February 2026, framing pay-per-use as opening the API back up to indie builders, early-stage products and hobbyists. That post is the first-party date for everything on this page, and it is why every table here carries a read date rather than a vague "as of 2026".

What the change did is convert a subscription question into an arithmetic one. On the published rate, $200 of credits buys 40,000 post reads or 20,000 user lookups. $5,000 of credits buys 1,000,000 post reads.

That second number is worth pausing on. The old Pro price divided by the old Pro volume works out to exactly $0.005 per post, which is precisely the current pay-per-use post read rate. X did not cut the unit price when it moved to credits. It kept the highest-volume unit rate and removed the commitment, which is why the change is enormous for small projects and close to neutral for large ones.

The practitioner reaction captured this before most published pricing pages did. A thread framed it as 1,000 post reads costing $5 instead of $200, which is correct: at $0.005 a resource, a thousand reads is five dollars, and there is no longer a subscription underneath it.

Not everyone agrees the change is favourable, and the disagreement is worth working through rather than picking a side of.

Aakash Gupta, who writes the Product Growth newsletter to a stated 215,000-plus subscribers, put the counter-case to 92,000 views: "Social Media Today ran the numbers on the new pay-per-use model, and for the same usage the $200/month Basic plan covers, it would cost $575/month under the new system. The per-request pricing is actually more expensive for typical use cases."

Check that against the quota he cites in the same post, which is $200 a month for 15,000 tweet reads. At $0.005 a post read on X's published sheet, 15,000 reads is roughly $75, comfortably under $200. So on the quota alone, pay-per-use is cheaper by a factor of 2.7. The $575 figure, which is his and not ours, has to be describing usage well above that quota, most likely once user lookups at $0.010 and expansions are included, and neither we nor the post states the workload it assumes.

Both things can be true, and this is the actual answer to the question. On the read quota the old plan advertised, pay-per-use wins. On the usage a real Basic-tier project generated, which was frequently above the quota because the quota was the constraint people designed around, it can lose. That is why this post prices a named workload instead of a tier, and it is why the break-even section below states thresholds rather than a verdict.

There is one constraint the old tiers did not have. Pay-per-usage accounts are capped at 3 million post reads per monthly billing cycle. At the published rate that is a $15,000 ceiling, and X's own page says the route past it is an Enterprise plan. So the plan structure did not disappear entirely, it moved to the top of the range. The X API pricing change post tracks the migration in more detail.

Does the X API still have a free tier, and what does it include?

Not in the documentation, as of 2026-09-09. We read four of X's public pay-per-use pages that day, the Introduction, the Pricing page, Getting Access, and About the X API, and none of them publishes a free read allowance. All four describe credit-based billing with no free quota named.

State that precisely, because the careful version and the loose version are different claims. What is true is that X's current public documentation does not document a free tier. What we cannot say is that no free access exists anywhere, because X names the Developer Console as the source of current rates and that console sits behind a login we did not authenticate into.

The only item on X's pricing page with the word free attached to it is a rebate paid in xAI API credits, and that rebate is 0 percent below $200 of cumulative spend in a billing cycle. It rises to 10 percent at $200, 15 percent at $500, and 20 percent at $1,000. That is credit on a different product, not a discount on the X bill, and it is worth nothing to a developer evaluating whether they can try the API before paying.

This matters because the loudest complaint in this whole topic was never the price, it was the cliff. The old structure gave you a tiny free allowance and then asked for $200 a month, so a side project had to justify $2,400 a year before it had a single user. Pay-per-use removes the cliff at the bottom and leaves the evaluation problem: you still have to load credits before your first billed call.

Where free credit does exist: the residential-proxy scraper API in the table below gives every new account 5,000 credits a month, worth roughly $7.50, with no card. TwitterAPIs gives $0.50 at signup with no card, which is about 625 standard calls or roughly 12,500 tweets. Our free Twitter API credit page covers what that allowance actually reaches, and is the Twitter API free covers the question in more depth.

Is the xAI credit rebate worth anything on a real bill?

It is worth up to 20 percent of your X spend, paid in credit on a different product, and it is zero until you have spent $200 in a billing cycle. Whether that is worth anything depends entirely on whether you were going to buy that other product anyway.

The mechanics, from X's own pricing page and xAI's billing documentation. Cumulative spend inside a billing cycle sets the rate: 0 percent below $200, 10 percent from $200, 15 percent from $500, and 20 percent from $1,000. The rate applies to your entire cumulative balance, and you receive the delta between what is newly owed and what has already been credited. Your cumulative total resets at the start of each cycle. You have to link an xAI team, created on xAI's own API console, to your X developer account first, or the credit does not arrive at all.

Worked against the $5,000 monthly bill from earlier in this post: that spend sits in the 20 percent band, so it returns $1,000 in xAI API credits. On the $3,150 plain-post version it returns $630. On a $150 hobby month it returns nothing. The bands and the rebate share are read from X's own pricing page; every dollar figure in this paragraph is arithmetic on them.

Price it honestly. This is not a discount. Your X invoice is unchanged, and the credit is only worth face value if you have a workload for xAI's API and would otherwise have paid cash for it. If you do not, the correct valuation is zero, and the effective rate on your reads is still $5.00 per 1,000 tweets.

There is a second effect that is worth naming because it explains the design. The rebate only starts at $200, which is exactly the price point of the tier X retired. A developer who would have spent $200 a month under the old structure now gets pulled toward a second product at the same threshold. That is a distribution mechanism rather than a pricing concession, and reading it as a discount is how a budget ends up 20 percent optimistic.

How much does it cost to post a tweet through the X API, and why does a post with a link cost more?

A plain post is $0.015 per request. A post containing a URL is $0.200 per request. That is a 13.3x multiplier, and X lists it as its own separate line called Post: Create (with URL) rather than as a surcharge on the plain rate.

Derived from the per-request write rates on X's price sheet. Normalized: $15.00 per 1,000 plain posts, $200.00 per 1,000 link posts. A summoned post is $0.010, so $10.00 per 1,000. DM interaction creation and user interaction creation are both $0.015.

X publishes no rationale for the link differential on the pricing page, so we will not invent one. What we can state is the effect. Any automation whose entire purpose is distributing links, a news bot, a release feed, an alerting account, has a cost structure with almost nothing in common with a text-only account. At 100 link posts a day, the write leg alone is $20 a day, $600 a month. At 100 plain posts a day it is $1.50 a day, $45 a month. Both lines are arithmetic on the per-request write rates X publishes.

Automation operators surfaced this line item before most pricing pages listed it, and several publicly discussed shutting down or migrating over it specifically. We checked their figure against X's own price sheet on 2026-09-09 and it is exactly right, which is a useful reminder that the practitioner record is often ahead of the published summaries on this topic.

https://x.com/Tunables/status/2062529533215928355

Full write comparison, in one unit:

The TwitterAPIs Normalized Price Sheet, writes: dollars per 1,000 posts published

Action	Published rate	Per 1,000 posts	Multiple of a plain X post	Source
Official X, Post: Create (with URL)	$0.200 per request	$200.00	13.3x	published
Official X, Post: Create	$0.015 per request	$15.00	1x	published
Official X, Post: Create (summoned)	$0.010 per request	$10.00	0.67x	published
Official X, DM Interaction: Create	$0.015 per request	$15.00	1x	published
TwitterAPIs, tweet creation	$0.0016 per call	$1.60	0.11x	published
twitterapi.io	Not published on its pricing page	Unknown	Unknown	unknown
Apify and Bright Data read actors	No write endpoints	Not applicable	Not applicable	published

as of 2026-09-09

Note the shape of that table. Most read-focused vendors have no write path at all, so a posting workload has far fewer real options than a reading workload. This is the single most under-reported asymmetry in the market: pages that treat "the API" as one price are answering only the read half of the question.

Where do third-party Twitter API vendors land against the official rate?

Every one of them sits below the official read rate, and the spread between them is wider than most buyers expect. Converted to dollars per 1,000 tweets on 2026-09-09: the residential-proxy scraper API $0.75 per 1,000 records, the marketplace tweet actor $0.40, the per-tweet read API $0.15, and TwitterAPIs $0.04 at list page density. Each vendor is named in the normalized table below, and its rate source is listed with a link at the end of this post.

The TwitterAPIs Normalized Price Sheet, reads: dollars per 1,000 tweets

Provider	Published rate	Billing unit	Per 1,000 tweets	Multiple of cheapest	Source
Official X API, Posts: Read	$0.005 per resource	Resource returned	$5.00	125x	published
Official X API, Owned Reads	$0.001 per resource	Resource returned, own data	$1.00	25x	published
Bright Data Scraper API	$0.75 per 1,000 records	Record delivered	$0.75	18.8x	published
Apify Tweet Scraper V2	$0.40 per 1,000 tweets	Tweet result	$0.40	10x	published
twitterapi.io	$0.15 per 1,000 tweets	Tweet	$0.15	3.75x	published
TwitterAPIs, list density	$0.0008 per call, 20 per page	Call	$0.04	1x	derived
TwitterAPIs, delivered density	$0.0008 per call, 8 to 13 per page	Call	$0.06 to $0.11	1.5x to 2.8x	measured

as of 2026-09-09

One unit

Every provider converted to the same unit, so the columns can actually be compared

	Official X	Bright Data	Apify V2	twitterapi.io	TwitterAPIs
Per 1,000 tweets read	$5.00	$0.75	$0.40	$0.15	$0.04
Per 1,000 posts written	$15.00 to $200.00	No write path	No write path	Not published	$1.60
What one unit of billing is	A resource returned	A record delivered	A tweet result	A tweet	A call of up to 20
Repeat reads inside 24 hours	Deduplicated, soft guarantee	Billed again	Billed again	Billed again	Billed again
Hard monthly ceiling	3,000,000 post reads	None published	None published	None published	None published
Developer account required	Yes, reviewed	No	No	No	No

Three things in that table are worth calling out, because they are the places a naive comparison goes wrong.

The billing unit differs on every row. X bills a resource returned. The residential-proxy scraper API bills a record delivered. The marketplace tweet actor bills a tweet result. The per-tweet read API bills a tweet. We bill a call that carries up to 20 tweets. Converting a per-call rate to a per-tweet rate requires knowing page density, which is why we publish two rows for ourselves rather than one.

Nobody except X deduplicates. X suppresses a repeat charge for the same resource inside a 24-hour UTC window. Every per-call and per-result vendor bills you again. That single rule is the one thing capable of inverting the ranking, and it gets its own section below.

Unpublished is not zero. The per-tweet read API does not publish write pricing on its own pricing page, so its row in the write table reads "not published" rather than a guess. Its own published minimum works out to $0.15 per 1,000 calls, waived for bulk responses, and it notes a $1.50 per 1,000 charge for list function calls effective October 1. Those are its own terms; we have not tested them.

For a wider provider set with the same normalization applied, the cheapest Twitter API providers ranked by real per-1,000-tweet cost post covers eight, and the API alternatives comparison page carries the current shortlist.

Reads, normalized

What 1,000 tweets cost, once every vendor is put in the same unit

Point	Value (USD per 1,000)
Official X API	5 USD per 1,000
Bright Data	0.75 USD per 1,000
Apify Tweet Scraper V2	0.4 USD per 1,000
twitterapi.io	0.15 USD per 1,000
TwitterAPIs, delivered	0.11 USD per 1,000
TwitterAPIs, list	0.04 USD per 1,000

What does a worked monthly X API bill actually look like?

Take a named workload rather than an abstraction: 50,000 profile lookups, 500,000 tweet reads, and 10,000 published posts a month. That is a mid-sized brand monitoring plus outreach system, and it is a shape we see constantly.

Worked example

One month, three workloads, priced end to end before any code

Official X API, link posts: $5,000.00 · TwitterAPIs, delivered density: $96.00 · Ratio: 52x

☑ Read leg dominates on the official API at $2,500 of the $5,000 · ☑ Write leg is $2,000 only because every post carries a URL · ☑ Profile lookups bill at twice the post rate on the official API · ☐ twitterapi.io publishes no write rate, so its total cannot be completed

On the official API with every post carrying a link, that is $5,000.00 a month. On the same API with plain posts it is $3,150.00. On a per-call API at realistic delivered density it is $96.00. The official lines come from X's price sheet and the per-call line from our own pricing page.

A worked monthly bill: 50,000 profile lookups, 500,000 tweet reads, 10,000 posts published

Provider	Profile leg	Read leg	Write leg	Monthly total	Source
Official X API, every post carries a link	$500.00	$2,500.00	$2,000.00	$5,000.00	derived
Official X API, plain posts	$500.00	$2,500.00	$150.00	$3,150.00	derived
Bright Data Scraper API	$37.50	$375.00	No write path	$412.50	derived
Apify Tweet Scraper V2	$20.00	$200.00	No write path	$220.00	derived
twitterapi.io	$9.00	$75.00	Not published	$84.00 plus writes	derived
TwitterAPIs, delivered density	$40.00	$40.00	$16.00	$96.00	derived
TwitterAPIs, list density	$40.00	$20.00	$16.00	$76.00	derived

as of 2026-09-09

The arithmetic, so you can check it rather than trust it. The X profile leg is 50,000 at $0.010, which is $500. The X read leg is 500,000 at $0.005, which is $2,500. The X write leg is 10,000 at either $0.015 or $0.200, which is $150 or $2,000.

The per-call side converts subjects to calls first, which is the step people skip. 500,000 tweets at 10 delivered per page is 50,000 calls, and 50,000 calls at our published $0.0008 call rate is $40. At the list ceiling of 20 per page it would be 25,000 calls and $20. We use the realistic figure in the headline because using the list figure would flatter us by exactly 2x. The call rate and the delivered page range are both published on our pricing page.

Note also what the profile leg does. On the official API, profile lookups cost twice a post read, so 50,000 profiles is 500 dollars against 500,000 posts costing 2,500 dollars. Ten times fewer subjects, one fifth the cost. On a per-call API both legs bill at the same standard rate, so the profile leg is proportionally larger. Sizing the two legs separately is the difference between an estimate and a guess. The X API cost per user analysis takes this further into unit economics.

What is the break-even volume where pay-per-use beats a subscription?

40,000 post reads a month against the old $200 price point, and 1,000,000 against the old $5,000 one. Those are the two numbers people ask for and almost nobody states.

Break-even volumes: where each price point stops being the cheaper option

Threshold	Volume	What it means	Source
$200 a month of credits, post reads	40,000 post reads	Below this, pay-per-use is cheaper than the old $200 price point	derived
$200 a month of credits, user lookups	20,000 user lookups	Profiles burn credits twice as fast as posts	derived
$5,000 a month of credits	1,000,000 post reads	The old Pro price divided by the current rate, exactly $0.005 per post	derived
Pay-per-usage monthly cap	3,000,000 post reads	$15,000 at list rate, then Enterprise is the only route up	derived
$200 of credits on a per-call API	250,000 calls	Roughly 2,000,000 to 5,000,000 tweets depending on page density	derived
Write ceiling, per app	10,000 posts per 24 hours	A rate limit, not a price. No budget lifts it	published

as of 2026-09-09

The derivation is one division each: $200 divided by $0.005 is 40,000, and $5,000 divided by $0.005 is 1,000,000. Against user lookups the first threshold halves to 20,000, because a profile costs twice a post.

Against a per-call API the crossover moves by nearly an order of magnitude. $200 of credit at $0.0008 a call is 250,000 calls, which is 2,000,000 to 5,000,000 tweets depending on how full your pages come back. So the same $200 buys 40,000 tweets on the official API and somewhere between two and five million on a per-call one.

There is a threshold in the table that is not a price at all. POST /2/tweets is limited to 10,000 requests per 24 hours per app on X's own rate-limit reference. No amount of credit lifts it. That is a genuinely different kind of constraint from everything else on this page, and it is covered properly in the throughput section below and in our rate limits guide.

Where the ranking gets unstable is not at any of these thresholds. It is on repeated reads, which is next.

What does the 24-hour deduplication rule do to a polling bill?

It is the one rule capable of making the most expensive rate card produce the cheapest invoice, and exactly one competitor page names it at all. None prices it.

X deduplicates all billable resources within a 24-hour UTC window. Request the same post twice in a day and you are charged once. The window resets at midnight UTC. X calls this a soft guarantee and states that edge cases such as service outages may result in resources not being deduplicated, so it is a strong default rather than a contractual one.

The one workload that inverts the ranking

Where a repeated read stops billing, and where it does not

Priced against a real polling loop, the effect is enormous. The rule is worth modelling before you pick a poll interval, because the overlap share moves the bill by an order of magnitude:

# What the 24-hour deduplication window does to a polling bill.
POLLS_PER_DAY  = 96              # every 15 minutes
POSTS_PER_POLL = 100             # page size
OVERLAP        = 0.90            # share of each page already seen today
PER_POST       = 0.005           # X, per post returned

deduped = POSTS_PER_POLL * POLLS_PER_DAY * (1 - OVERLAP) * PER_POST
flat    = POSTS_PER_POLL * POLLS_PER_DAY * PER_POST
print(f"with dedup ${deduped:,.2f}/day, without ${flat:,.2f}/day")
# with dedup $4.80/day, without $48.00/day

What the 24-hour deduplication rule does to a polling bill

Scenario	Charged items per day	Daily cost	30-day cost	Source
Official X, 1,000-post set polled every 5 minutes, no dedup	288,000 resources	$1,440.00	$43,200.00	derived
Official X, same loop with the 24-hour UTC dedup applied	1,200 distinct resources	$6.00	$180.00	derived
TwitterAPIs, same loop, per-call billing, no cursor	14,400 calls	$11.52	$345.60	derived
TwitterAPIs, same loop with a since_id cursor	60 calls	$0.05	$1.44	derived

as of 2026-09-09

Take a brand monitor re-fetching a 1,000-post result set every five minutes, 288 times a day, across which 1,200 posts are genuinely new. Without deduplication that is 288,000 resource charges a day, which is $1,440 a day and $43,200 a month. With the 24-hour window applied it is 1,200 distinct charges, $6.00 a day, $180 a month. The window and the per-resource rate are both X's; the daily and monthly totals are arithmetic on them.

Now run the identical loop against a per-call API with no cursor. 1,000 posts at 20 per page is 50 calls a poll, 14,400 calls a day, $11.52 a day, $345.60 a month. On this workload the official API is roughly 1.9x cheaper. That is the honest finding and we are not going to bury it.

The fix is not a different vendor, it is a cursor. Pass a since_id so each poll fetches only what is new. 1,200 new posts at 20 per page is 60 calls a day, which is five cents a day and $1.44 a month, 125x under the deduplicated official bill, at the call rate on our pricing page. Deduplication is X charging you correctly for a mistake in your polling loop. A cursor is not making the mistake.

The general rule, and the reason this section exists: per-resource billing rewards a naive loop and per-call billing rewards a correct one. If you cannot change the loop, the deduplication window is worth real money. If you can, it is worth nothing.

What does historical and full-archive search cost as its own line item?

On the official API, nothing extra per resource. Full-archive search bills at the same $0.005 a post as recent search. What changes is throughput, not price: X limits GET /2/tweets/search/all to 1 request per second and 300 per 15 minutes, with a 500-result ceiling per request.

On a per-call API the premium is explicit rather than hidden in a rate limit. Full account history bills at $0.0024 a call against the $0.0008 standard, a 3x premium. Full thread expansion bills at $0.004, a 5x premium. Those are the two most expensive endpoints on our pricing page and they are expensive for a reason: reconstructing a complete history or a complete reply tree costs materially more upstream than reading a page of recent posts.

Sized on a one-million-tweet backfill, the two models produce very different bills. On the official API, 1,000,000 post reads is $5,000, and it consumes a third of the 3 million monthly cap in one job. On a per-call API at the full-history rate and 13 delivered per page, it is roughly 76,900 calls at $0.0024, which is about $185.

The rate-limit ceiling is the part that catches people. At 300 requests per 15 minutes with 500 results each, the theoretical official ceiling is 150,000 posts per 15-minute window per app. A one-million-post backfill therefore takes a minimum of about 100 minutes of continuous, perfectly-paced requesting, before any retry. Budget the wall clock, not just the dollars. The cost of a 1M tweet dataset post runs this exercise at full length.

Collapsing all reads into one rate, which every competitor page in this set does, hides both of these facts.

What do webhooks and streaming cost, and why is that a separate rate card?

Webhook events delivered through X's Activity API bill per event delivered, on their own list of rates, and they are deduplicated inside the same 24-hour UTC window as everything else. This is the part of the price sheet that almost no comparison page mentions, and it is the one that decides whether an event-driven architecture is affordable.

The published per-event rates, read 2026-09-09. A post.create event is $0.005. A follow or unfollow is $0.010 each. A mute or block, in either direction, is $0.001, all of it from X's own account-activity rate card. A profile update is $0.005. A received chat message is $0.010 and a received DM is $0.010. A news item is $0.005, and a Space starting or ending is $0.005 each.

Then the list of what is not billed at all, which is where the design intent shows: post.delete, chat.sent, chat.conversation_join, dm.sent, dm.read, and dm.indicate_typing. X charges you for inbound signal and not for the echo of your own outbound actions.

Size that against a real monitoring account. Following 500 accounts that collectively post 200 times a day gives 200 post.create events a day, which is $1.00 a day and $30 a month. Follow-graph churn on those 500 accounts at 50 events a day adds $0.50 a day, on the per-event rates X publishes. That is a genuinely cheap architecture compared to polling the same 500 timelines, which is the point: push is priced below pull because X does the fan-out once.

The filtered stream is separately constrained rather than separately priced. X allows one connection with up to 1,000 rules, each rule up to 1,024 characters, delivering up to 250 posts a second, and the posts themselves bill at the standard $0.005 read rate. So a busy rule set is a price problem and a busy connection is a throughput problem, and they arrive independently.

Rate limits and price: which one binds first?

On reads, the money runs out first. On writes, the rate limit does. Those are two genuinely different failure modes and conflating them is the most common expensive mistake in this topic.

Take recent search. X allows 450 requests per 15 minutes per app with 100 results maximum, which is a theoretical 45,000 posts per 15-minute window, or 4,320,000 posts a day. But pay-per-usage caps you at 3,000,000 post reads a month. So on search reads you will exhaust a month of quota in roughly 17 hours of running at the rate limit. The price binds long before the throughput does.

Now take posting. POST /2/tweets allows 10,000 requests per 24 hours per app. At $0.015 a plain post, hitting that ceiling every day costs $150 a day. At $0.200 for link posts it is $2,000 a day. Either way the ceiling is 10,000, and no budget raises it. The rate limit binds first, absolutely.

A few more from X's own rate-limit reference, read 2026-09-09: GET /2/tweets is 3,500 per 15 minutes per app, timelines are 10,000 per 15 minutes per app, follower lookups are 300 per 15 minutes, and the filtered stream allows one connection with up to 1,000 rules delivering up to 250 posts a second.

The per-endpoint windows themselves, and what each one means when you hit it, are laid out in the Twitter API rate limit guide and in what rate limited means on X.

The practical instruction: build two budgets, one in dollars and one in requests per window, and check which one your workload hits first. A team that has only built the dollar budget will be surprised by a 429 and a team that has only built the request budget will be surprised by an invoice. The Twitter API reference hub carries the full endpoint picture, and our own rate limits guide covers the per-call side.

Check the meter rather than waiting for the invoice. X exposes daily consumption on its own usage route, so a budget can be tracked in the same loop that spends it:

curl -s "https://api.x.com/2/usage/tweets?days=7" \
  -H "Authorization: Bearer $X_BEARER_TOKEN" \
  | python3 -c "import sys,json; d=json.load(sys.stdin)['data']; print(d['project_cap'], d['project_usage'])"

What does X Enterprise access cost, and who actually needs it?

X publishes no Enterprise price. Its documentation routes an Enterprise enquiry to an interest form rather than to a rate card, and we confirmed that form resolves on 2026-09-09.

The only citable public figures are from 2023. Wired, reporting by Chris Stokel-Walker on 10 March 2023, described a $42,000 per month tier with pricing starting at $500,000 a year for access to 0.3 percent of posts. Treat that as historical context and not as a current quote. It is three years old, it predates the entire pay-per-use migration, and X has published nothing since to confirm or replace it.

Who needs Enterprise is answerable from current documentation without any pricing at all. Two groups.

The first is volume. Pay-per-usage caps at 3 million post reads per monthly billing cycle, which is $15,000 a month at the published rate. Past that, X's pricing page says the route is an Enterprise plan. There is no third option.

The second is product. Enterprise covers things pay-per-usage simply does not include: PowerTrack, Decahose, compliance streams, the firehose, and the historical GNIP product family. If your requirement is a complete filtered stream of the platform rather than a high volume of reads, volume was never the issue and no amount of credit purchases the capability.

Everyone else, and that is the overwhelming majority of teams asking this question, is not an Enterprise buyer. The reason "what does Enterprise cost" is such a common query is that the 2023 numbers were shocking enough to become the default mental model for X API pricing generally, which is a separate problem covered below.

Do I need an X developer account to pull tweet data?

For the official API, yes, without exception. X's Getting Access documentation requires signing in at console.x.com, reached from the X developer portal, accepting the Developer Agreement and Policy, completing a profile describing your intended use, creating an app, and saving credentials that are displayed exactly once.

You then choose an auth mode. A Bearer Token covers app-only reads of public data. OAuth 2.0 or OAuth 1.0a covers acting on behalf of a user, which is required for posting, liking, following, and DM access. That is four artifacts to manage before a single billed call. The flow is fiddly enough that step-by-step video walkthroughs of getting an X API key are a content category of their own, which is a signal about the setup cost rather than about the price.

For third-party read APIs, no. They operate their own access layer and issue a key directly, so a bearer token in a request header is the whole setup. There is no application, no review, no OAuth redirect, and no use-case description to write. TwitterAPIs works this way across 99 endpoints, 63 reads and 36 writes, and new accounts start with $0.50 of credit and no card.

The distinction is worth stating plainly because it is a real cost, not just a convenience. A review queue is wall-clock time on the critical path of a project, and it is time you cannot estimate in advance because X publishes no service level for it. If your evaluation window is a weekend, the official route may not fit inside it regardless of budget.

Both routes read the same public conversation. The difference is who runs the access layer and what you have to prove before you get a key. Our MCP server exposes the same endpoints to agent frameworks with the same key, if that is the shape of your integration.

Why did the Twitter API price go up, and has it come back down?

It went up in 2023 and, for low-volume work, it has come down a long way since, measured against X's current price sheet. For high-volume work it did not come down, it became linear. Which of those two sentences applies to you depends entirely on your monthly read count.

The timeline, with sources. In February 2023 free API access ended for both v2 and v1.1, announced by the platform's own developer account and carried widely. In March 2023 Wired reported the $42,000 per month enterprise tier and the $500,000 a year floor for 0.3 percent of posts. In April 2023 New York City's subway ended its Twitter service alerts after an MTA official said Twitter had asked for $50,000 a month. Between 2023 and 2025 the structure was fixed tiers. In 2026 pay-per-use replaced them, as X's current price sheet shows.

For a project reading 1,000 posts a month, the 2023 answer was a $200 subscription and the 2026 answer is $5.00. That is a 40x reduction and it is real. The crossover is one division, so run it against your own volume rather than taking ours:

# Break-even monthly READ volume: below this, pay-per-use beats the old flat plan.
OFFICIAL_PER_POST = 0.005        # X, per post returned
for label, monthly in (("Basic", 200.00), ("Pro", 5000.00)):
    print(f"{label}: pay-per-use is cheaper below {monthly / OFFICIAL_PER_POST:,.0f} posts a month")
# Basic: pay-per-use is cheaper below 40,000 posts a month
# Pro: pay-per-use is cheaper below 1,000,000 posts a month

For a project reading 3,000,000 posts a month, the 2026 answer is $15,000 and then a cap. Whether that is better or worse than the 2023 answer depends on which tier you would have been on, and since the old quotas are no longer documented anywhere first-party, we are not going to pretend to a precise comparison.

What has not come back is trust, and that is a legitimate input to a buying decision rather than just sentiment. Every pricing thread on this topic still anchors to 2023, and the reason is structural: the pricing model changed twice in three years, X's own page states that prices are subject to change and directs you to the Developer Console for current rates, and there is no published commitment to any rate. Architect for the possibility that a rate moves. That means an abstraction layer over your data source, not a hard dependency on one vendor's response shape. The official X API versus third-party comparison works through what that abstraction costs to build.

https://x.com/aakashgupta/status/2019991413442900046

What costs show up on an X API bill that the rate card does not show?

Five, consistently, and the first two are usually larger than everything else combined.

Fan-out. One subject frequently requires several calls. Scoring a prospect might need a search, a profile read and a timeline read, so 1,000 prospects is not 1,000 reads. No rate card can state your fan-out because it is a property of your call graph, not of the API. This is the single biggest gap between an estimate and an invoice.

Pagination waste. You price a page at its ceiling and receive it at its actual density. If you budget 20 items and receive 8, your real per-item cost is 2.5x your estimate. This applies to every per-call vendor including us, which is why we publish the delivered range alongside the list rate rather than only the flattering number.

Retries. A call that fails after returning resources can still have billed for them. A retry loop with no idempotency awareness quietly doubles a leg. On the official API's per-resource model this is especially easy to miss, because the failure and the charge are attached to different things.

Field expansions. Expanding an author on a post read adds a user resource at $0.010, which is twice the post itself. A search returning 1,000 posts with author expansion is not $5.00, it can be up to $15.00 depending on how many distinct authors appear. Expansions are the most common way a read leg doubles without anyone changing the query.

Write asymmetry. A link post is 13.3x a plain post and it is a separate line item, not a percentage surcharge. A scheduler that mixes both will have a bill dominated by whichever subset carries URLs, regardless of the volume split.

Our Twitter API cost benchmark post measures several of these against real traffic rather than modelling them.

How do the spending controls work, and where do they bite?

X ships three cost controls, and each one has a failure mode documented on its own pricing page. Read them before you turn any of them on, because two of them can stop your service rather than just capping your spend.

Spending limits. Set a maximum per billing cycle. When you hit it, API requests are blocked until the next cycle begins. That is a hard stop on your product, not a warning, so a limit set too tight is an outage with a billing cause. Set it above your worst realistic month, not at your expected one.

Auto-recharge. Configure a recharge amount and a trigger threshold, for example add $25 whenever the balance drops below $5, using the spend controls X documents. It requires a saved default payment method. It has two safeguards that behave like constraints: at most one top-up per five-minute window, and it does not run at all while your balance is zero or negative.

Those two safeguards combine into a specific failure X documents explicitly. If your usage is bursty enough to drain a full recharge in under five minutes, you can still see out-of-credits errors with auto-recharge switched on. The fix is to raise the recharge amount so one top-up comfortably outlasts a five-minute window of your peak consumption, not to lower the trigger.

Balance behaviour. A balance can go slightly negative, and once it does, requests are blocked until you cover the shortfall. Auto-recharge will not dig you out, because it is paused at a negative balance. That combination means a burst can leave an account both negative and unable to self-heal, which is a manual intervention at whatever hour it happens.

The threshold arming rule is a small detail with a real consequence. Auto-recharge fires the first time your balance drops below the threshold after having been at or above it, and a balance exactly equal to the threshold counts as armed. Buy $5 of credits with a $5 trigger and your very first spend triggers a top-up.

Instrument alongside all of this rather than relying on it. X exposes a usage endpoint returning daily post consumption, which is the only way to see a leg drifting before the invoice does.

Is a per-call API cheaper than a monthly subscription at my volume?

Below 40,000 post reads a month, yes by a wide margin, and pay-per-use also beats the old $200 price point on the official API. Between 40,000 and 3 million reads, per-call vendors stay cheaper on published rates and the gap in absolute dollars is what starts to matter. Above 3 million post reads you are past X's cap and into an Enterprise conversation regardless.

The exception is the polling pattern covered above. If your workload re-reads the same resources many times a day and you cannot add a cursor, X's 24-hour deduplication window is worth more than any per-unit discount. That is the only scenario in this entire analysis where the official API is the cheaper choice on read volume, and it is a real one.

Two further considerations that are not price.

Write coverage. If you need to publish, most read-focused vendors have no write path at all. That narrows your options far more sharply than any read rate does, and it is the question to settle before comparing read prices.

Access latency. The official route requires a reviewed developer account with no published turnaround. A per-call API issues a key immediately. On a project with a fixed deadline that is a scheduling constraint, not a preference.

For the structured version of this decision across the whole market, how to choose a Twitter API is the hub for this cluster, and the Twitter API cost breakdown covers total cost of ownership including the engineering time each route consumes.

How do I estimate my monthly X API bill before writing any code?

Five steps, in this order. The order matters more than any individual number, because getting the unit wrong at step two makes every later multiplication wrong by the same factor.

Step 1. Count subjects, not calls. How many posts, user profiles and write actions do you need a month? Subjects are what your product needs. Calls are an implementation detail you have not decided yet.

Step 2. Find the billing unit for each provider. X charges per resource returned. The marketplace tweet actor charges per tweet result. The residential-proxy scraper API charges per record. The per-tweet read API charges per tweet. We charge per call of up to 20 tweets. You cannot compare rates until every one of them is in the same unit, which is the entire point of the normalized sheet above.

Step 3. Apply fan-out and page density. Divide your subject count by the items each call actually delivers. For per-resource providers this step is a no-op, which is genuinely simpler. For per-call providers, use the low end of the published density range, not the ceiling.

Step 4. Price each leg separately. Do not use a blended rate. On the official API a user read is twice a post read and a link post is 13.3x a plain post, so a blended rate will be wrong in a direction you cannot predict.

Step 5. Add the extras. Retries, pagination waste, field expansions, and any historical backfill at its own premium rate. A 20 percent buffer on a first estimate is not padding, it is the fan-out you have not discovered yet.

Then instrument it. X exposes a usage endpoint that returns daily post consumption, so you can track against the budget rather than waiting for an invoice. On our side, the cost calculator runs steps 3 and 4 for you against the current rate card, and pay-per-use pricing carries the per-endpoint detail.

The most common version of this question, asked constantly and almost never answered with a number, is some form of "I want to gather all posts matching a set of search phrasings, ongoing, for one team, what do I need?" Run it through the five steps. Say the phrasings match 5,000 posts a day. That is 150,000 posts a month: $750 on the official API, roughly $12 to $17 on a per-call API at real density, and comfortably inside every rate limit involved. The answer was always a calculation, not a tier.

https://reddit.com/r/learnprogramming/comments/1nl918o/do_i_need_a_premium_tier_of_twitter_xs_api/

Measure your own page density before you trust any per-1,000 figure

Every per-call rate in this post converts to a per-tweet rate through one number: how many items a page actually returns. That number is a property of your queries, not of the vendor, so the only trustworthy version of it is the one you measure yourself. It takes one request.

Pull a single page and count what comes back:

curl -s "https://api.twitterapis.com/twitter/tweet/advanced_search?query=%22x%20api%20pricing%22&product=Latest" \
  -H "X-API-Key: $TWITTERAPIS_KEY" \
  | python3 -c "import sys,json; d=json.load(sys.stdin); print(len(d.get('tweets',[])))"

Then turn the count into a real unit cost. One standard call is $0.0008, so the per-tweet cost is that divided by whatever the line above printed:

CALL_PRICE = 0.0008          # standard read call
items_returned = 8           # replace with YOUR measured count

per_tweet = CALL_PRICE / items_returned
print(f"${per_tweet:.6f} per tweet, ${per_tweet * 1000:.4f} per 1,000")
# 8 items  -> $0.000100 per tweet, $0.1000 per 1,000
# 13 items -> $0.000062 per tweet, $0.0615 per 1,000
# 20 items -> $0.000040 per tweet, $0.0400 per 1,000

Three runs of that on your own real queries will tell you more than any comparison table, including this one. Dense queries on active topics fill pages. Narrow queries on quiet accounts do not, and a page that returns 3 items costs you $0.000267 a tweet, which is six times the list figure at the call rate on our pricing page.

Now size a whole month from the same measurement:

POSTS, PROFILES, WRITES = 500_000, 50_000, 10_000
DENSITY = 8                  # your measured items per page

read_calls  = POSTS / DENSITY
read_leg    = read_calls * 0.0008
profile_leg = PROFILES * 0.0008
write_leg   = WRITES * 0.0016        # tweet creation is the premium rate

print(f"reads ${read_leg:,.2f} + profiles ${profile_leg:,.2f} + writes ${write_leg:,.2f}")
print(f"total ${read_leg + profile_leg + write_leg:,.2f}")
# reads $50.00 + profiles $40.00 + writes $16.00
# total $106.00

Run the equivalent against the official API by multiplying subjects directly, since per-resource billing has no density step: 500,000 at $0.005 plus 50,000 at $0.010 plus 10,000 at $0.015 is $3,150.00. That asymmetry, one model needing a measured density and the other not, is the single largest source of wrong estimates in this topic.

Industry context: what actually changed in the Twitter data market

The market restructured twice in three years, and both restructurings happened for reasons that have nothing to do with developers.

The 2023 change closed the platform. Free access ended, third-party clients were shut off, and the enterprise floor moved to figures Wired reported at $42,000 a month. The stated logic was that platform data had commercial value being given away. The practical effect was that an entire category of small tools disappeared and a category of third-party access providers grew to replace them.

The 2026 change re-opened the bottom of the market without re-opening the top. Removing the monthly floor made small projects viable again, at $5.00 for a thousand reads instead of $200 for a subscription. Keeping the unit rate at the old Pro level, and adding a 3 million read cap, means nothing changed for anyone large.

Read those two together and the strategy is legible: X wants breadth at the bottom, where credit purchases are frictionless and now come with an xAI credit rebate that pulls developers toward a second product, and it wants contracts at the top. The middle, which is where most commercial data work actually sits, is the part being priced rather than courted.

That is also why the third-party layer did not shrink after pay-per-use launched. Every vendor in the normalized table above is still cheaper per tweet than the official rate, several by two orders of magnitude, and the 2023 experience taught the buyer side to keep an abstraction between their product and any single data source.

The current practitioner conversation reflects a market that has not caught up. Most developers are still pricing off a rate sheet that no longer exists, which is why threads announcing the pay-per-use change read as news months after it shipped, and why the $200-a-month complaint threads they are answering are still the ones that surface first on the query.

https://x.com/yongfook/status/2074000371908043033

The architectural consequence is real and under-discussed. Tools that previously charged $29 to $49 a month because they had to absorb a fixed $200 API bill can now ship as a one-time purchase where the user supplies their own API key. Pay-per-use did not just change what data costs. It changed which products are viable to build.

https://reddit.com/r/Superframeworks/comments/1t85ngg/x_killed_its_200mo_api_plans_payperuse_is_live/

What we would do at each volume band

Not advice about our own product, a decision rule you can apply against any of the rates above.

Under 10,000 posts a month. Anything works and the price difference is noise. Optimize for time to first call, which means whichever route does not require a review queue. On the official API this band costs under $50.

10,000 to 500,000 posts a month. This is where the normalized sheet earns its keep. The official API runs $50 to $2,500, a per-call API runs roughly $0.40 to $55 at real density. The decision is whether you need write endpoints, because that narrows the field faster than price does.

500,000 to 3 million posts a month. The official API runs $2,500 to $15,000 and the cap is now visible. At this band build the abstraction layer, because a rate change or a cap becomes an operational event rather than an inconvenience.

Above 3 million posts a month. You are having an Enterprise conversation on the official side whether or not you want one. Price a per-call vendor beside it in the same unit before you take the meeting, because the normalized comparison at this volume is a large number either way.

Any band, if you re-poll. Check the deduplication section before anything else. It can move the answer by two orders of magnitude in either direction depending on whether you cursor.

To see the same reasoning applied to acquisition rather than cost, how to scrape tweets covers the mechanics, and Twitter advanced search operators covers narrowing a query so you pay for fewer irrelevant results in the first place, which is the cheapest optimization on this entire page.

Methodology

Every rate in this post was read from the emitting system, meaning the vendor's own live pricing page, on 2026-09-09. No figure was taken from a listicle, a comparison blog, or a secondary summary, because a price quoted about a vendor is a claim and a price published by the vendor is a fact.

Official X rates come from X's pay-per-usage pricing documentation, whose own page schema records a dateModified of 2026-08-13. Rate limits come from X's rate-limit reference. Access requirements come from its Getting Access page. Where X publishes no figure, most importantly Enterprise pricing, this post says so rather than substituting a third-party estimate.

Third-party rates come from each vendor's own published pricing page or marketplace listing, linked per row in the source list, each read the same day. Where a vendor does not publish a rate for an operation, the table says not published. No cell in any table is an estimate presented as a rate.

Our own rates come from our pricing page, and the delivered page density used in every worked example, 8 tweets on a search page and about 13 on a timeline page, is published there too. We used the delivered range rather than the 20-item list ceiling in every comparison, which makes our numbers roughly 2x worse than the flattering version and is the only defensible way to run this comparison.

Every derived figure is one multiplication or one division from a published rate, and each table states which. Rows are tagged measured, derived, published or unknown, positionally. Anything we could not establish is tagged unknown rather than given a better-sounding label.

What would falsify this post: pull one page from any provider listed, count the items it returns, divide the billed amount by that count, and compare against the per-1,000 figure in the normalized table. If the two disagree by more than page density accounts for, the table is wrong and we want to know.

Rates change. X's own page states that prices are subject to change and names the Developer Console as the source of current figures. This post carries its read date on every table for that reason. We refresh it against every source listed here on a 90-day cycle.