X API Pay-Per-Use vs Scraping in 2026: What 10,000 Tweets Actually Costs

In February 2026, X changed how developers pay for data. The subscription tiers that defined the previous three years — Basic and Pro — closed to new signups. New developers now get a metered, pay-per-use model with no monthly minimum and no contract.

That is a genuinely better deal for small projects and a worse one for large ones. This post does the arithmetic both ways, against the alternative of scraping public pages, and is explicit about where each approach breaks.

TL;DR: X now charges $0.005 per post read, capped at 2 million reads per month. Our Twitter / X Scraper charges $0.003 per tweet with no ceiling. That makes scraping ~40% cheaper per read — but the API is authorized access that reliably returns data, and the scraper is subject to X’s login gate. Below roughly 10,000 tweets a month the difference is a rounding error and you should use whichever you trust more.

What the official API actually costs now

Straight from X’s developer documentation:

Item	Price
Post read	$0.005 per resource
Post read, owned by a user authenticated with your app	$0.001 per resource
Post create	$0.015 per request
Post create containing a URL	$0.200 per request
Monthly cap, pay-per-use	2,000,000 post reads
Above the cap	Enterprise plan required

Two details that materially change the math and get left out of most comparisons:

Deduplication. X deduplicates inside 24-hour UTC windows. Requesting the same post twice in that window does not charge twice. If your workload is polling a fixed set of accounts or a slow-moving search, your effective cost is well below the sticker price. Anyone quoting you a cost model that multiplies raw request count by $0.005 is overstating it.

The owned-reads discount. Reads of posts by users who authenticated through your own app cost $0.001 — five times cheaper than the standard rate, and cheaper than any scraper. If you are building a product where your users connect their own X accounts, the official API is simply the correct answer and nothing in this post applies to you.

The cost comparison

Our Twitter / X Scraper is priced at $3 per 1,000 tweets delivered, which is $0.003 per tweet, and charges nothing for a run that returns no data.

Tweets / month	X API @ $0.005	Scraper @ $0.003	Difference
1,000	$5	$3	$2
10,000	$50	$30	$20
100,000	$500	$300	$200
1,000,000	$5,000	$3,000	$2,000
2,000,000	$10,000	$6,000	$4,000
5,000,000	Enterprise plan	$15,000	—

Note what happens in the last row. Pay-per-use stops at 2 million reads per billing cycle. That is not a soft limit you can pay to exceed at the same rate — it is the ceiling of the plan, and beyond it you are negotiating an Enterprise contract. For a research team doing large historical collection, that ceiling matters more than the per-unit price.

Under 10,000 tweets a month, the absolute difference is $20. Choose on reliability, not cost.

Where the official API wins

I would rather be straight about this than sell you a scraper you should not buy.

• It is authorized access. You are within X’s terms, with a contract and a support path. For anything customer-facing, regulated, or resold, that alone decides it.
• It reliably returns data. No login gate, no proxy variance, no empty runs.
• Owned reads are cheaper than any scraper, at $0.001.
• It exposes things scraping cannot see, including write access and account-level endpoints.
• Deduplication is generous for repeat-polling workloads.

Where scraping wins

• No ceiling. There is no 2 million per month wall.
• ~40% cheaper per read at standard rates.
• No developer account, no application, no approval. You are reading public pages.
• Pay only for delivered rows. A run that returns nothing costs nothing.

The caveat that decides it

X aggressively login-gates automated sessions. When it detects a non-authenticated browser, it redirects to the sign-in page and returns no tweets.

Our actor detects this explicitly, exits cleanly, and charges nothing for the run. But “charges nothing” is not the same as “returns your data.” Yield depends on the residential IP assigned to a given run, and some runs come back empty. If your pipeline needs a guaranteed number of tweets by a deadline, the official API is the honest recommendation.

That reliability gap is precisely why the pay-per-result billing model exists here. You are not paying for attempts. When X blocks the session, the cost of that failed run is $0.00 — the risk sits with us, not with you.

How to decide

• Building a product where users connect their own X accounts? Official API, owned-reads rate. Not close.
• Under ~10,000 tweets a month? Whichever you trust. The cost difference is $20.
• Brand monitoring, trend research, or dataset collection above 100,000 tweets? The scraper’s per-read price and absent ceiling start to compound, provided your workload tolerates variable yield.
• Above 2 million reads a month? The API’s pay-per-use plan cannot serve you at all. Enterprise or scraping.
• Anything regulated, resold, or contractually sensitive? Official API.

If the scraping route fits, the Twitter / X Scraper takes a keyword, hashtag, or handle and returns tweet text, author, verification status, likes, retweets, replies, views, media URLs, hashtags, and mentions as flat JSON — with nothing charged when X blocks the run.

---

X API prices in this post are from X’s official developer pricing documentation as of 27 July 2026. X notes that current rates may vary and that the Developer Console shows live pricing — check it before committing to a volume.