The rate card is not hard to find. What is hard is working out what you will actually be billed, because the things that decide that are mostly not on the rate card at all. This article is the version we needed while building on it.
What does the X API cost in 2026?
Quick answer
X uses pay-per-usage pricing with no subscription. Creating a post costs $0.015, or $0.200 if it contains a URL. Reading a post costs $0.005 per post returned, or $0.001 for your own data through certain endpoints. Pay-per-usage accounts are capped at three million post reads a month.
| Operation | Price | Billed per |
|---|---|---|
| Post: create | $0.015 | request |
| Post: create, containing a URL | $0.200 | request |
| Post: create, summoned reply | $0.010 | request |
| Posts: read | $0.005 | resource returned |
| User: read | $0.010 | resource returned |
| Owned reads, your own data | $0.001 | resource returned |
| Like, mute or block: read | $0.001 | resource returned |
| Trends, counts: all | $0.010 | request |
Those numbers are accurate and they will not tell you what you owe. Everything below is why.
Billable events are not API calls
This is the single thing that makes people's estimates wrong, and it is worth internalising before you model anything. X runs two separate meters that do not agree with each other.
- Rate limits count HTTP requests. One call is one call, whatever it does.
- Billing counts resources and billable categories. A read bills once per item returned. A write bills once per billable action, and some HTTP calls are not billable events at all.
X states the first half plainly: prices are per resource fetched for reads and per request for writes, and reads are charged per resource returned in the response. So a search returning 100 posts is 100 charges, not one. Pulling a thread bills for every post in it.
It goes further than that, and this was confirmed by X staff on 7 September 2026, the day before we published. Objects pulled in through expansions bill separately. Ask for posts and expand the author, and every returned user object is a $0.010 user read stacked on top of the $0.005 post read. A single request for 100 posts with authors expanded is not $0.50, it is up to $1.50.
The same arithmetic bites hardest on user lookups, which return up to 100 users per request at $0.010 each. As one developer who has built on this API for seventeen years put it in X's own forum, that means one ordinary call can cost a dollar. X staff replied confirming the pricing he had outlined was correct.
‼️ The second half is not documented anywhere. Each media object you attach is billed as its own post creation. A post with one image records two post-creation charges. A post with four images records five. This is not on the pricing page. It comes from an X staff member answering a developer who noticed it in their console on 30 August 2026, and the page still does not say it a week later.
The good news in the same answer is that the chunked upload calls, the appends and status polls, are not billed as post creations. That matters because open-source libraries disagree wildly about chunk size, from 250 kilobytes to 5 megabytes, which is a twenty-fold spread in call count for the same video. That spread hits your rate limits. It does not hit your invoice.
The link surcharge, and what nobody can tell you about it
A post costs $0.015. A post containing a URL costs $0.200. That is the most consequential number in the whole rate card, because link posts are exactly what most scheduling tools exist to publish.
Two things about it are worth knowing and are usually missing.
- It is recent. In the October 2025 pilot, creating a post cost $0.01 flat. On 20 April 2026 the base rate rose to $0.015 and the URL rate was introduced at $0.200 in the same change. This is a deliberate repricing, not a quirk inherited from the old API.
- X has never defined what counts as containing a URL. The phrase appears in exactly two places in the entire documentation corpus, the price table and the April changelog entry, and neither explains it. No endpoint page, no billing page, no FAQ.
What can be pieced together comes from staff answers in X's own developer forum rather than from documentation. A reply containing a link is charged the full $0.200 and does not get the cheaper summoned-reply rate. Quote posts are moot, because quote-posting through the API was removed from self-serve entirely in April. Whether an attached image or video triggers the rate, and whether X's own link shortener is what gets detected, are simply not answered anywhere.
The bills are real and they have names attached. One developer went from roughly $11 a month to roughly $150 overnight, having pushed a backlog of 1,400 posts through at the old penny rate days earlier. Another, running a free auto-posting service for several thousand artists at roughly 50,000 posts a month, worked out that his $200 plan had effectively become $9,600 and stopped using the API entirely. A third had 51 posts bill $10.20 in two days and opened a ticket assuming it was a bug.
The clearest illustration is not a bill at all. On the day the surcharge took effect, Techmeme announced it was removing links from its posts, saying in its own words that the cost of posting links through the API had increased that day by 1,900 percent. Its posts now tell readers to visit the site for the link. Whatever the surcharge was designed to discourage, what it actually stopped was one of the best known automated news accounts linking to journalism.
A smaller case makes the same point more sharply. An account posting debunks of misinformation, with links to sources, went from around fifteen posts a day to one, because its entire budget was thirty cents. X suggested quote posts or reusing media instead. Quote posting through the API requires Enterprise access, which is not available on pay-per-usage at all, and uploaded media identifiers expire after 24 hours. The workaround does not exist at the price point of the people who need it.
The same post can cost you five times more to read
This one is actionable in a way most pricing writing is not, and it is a straight consequence of how the owned-reads discount is scoped.
X gives a $0.001 rate for reading your own data, but only through a closed list of twelve endpoints, and only when the account you are reading is both the authenticated user and the owner of the developer app. Reading a post by its ID is not on that list.
| Route | Price per post | Returns |
|---|---|---|
| Fetch the post by its ID | $0.005 | One post per request |
| Fetch it from your own posts timeline | $0.001 | Up to 100 per request, with private metrics |
Same data, five times the price, decided by which endpoint a developer happened to reach for. If you are building anything that reads your own history at volume, that single choice is the difference between a manageable bill and a surprising one.
There is a caveat we will not paper over. X staff have told at least one developer that owned reads bill per request rather than per resource, which contradicts the documentation's own wording and would be another five-fold difference in the opposite direction. Two developers pushed back in that thread and it was never resolved. We are reporting the documented version and flagging that X's own people have said otherwise.
Deduplication, which almost nobody accounts for
Buried in the pricing page is a rule that makes polling far cheaper than the raw arithmetic suggests. Resources are deduplicated within a 24 hour UTC window, so if you are charged for a post and request it again inside that window, you are not charged again.
For a tool that refreshes metrics several times a day, that changes the model entirely. It also comes with X's own hedge, quoted exactly: deduplication is a soft guarantee, and edge cases such as service outages can result in resources not being deduplicated. So it is cheaper than you think, and you cannot rely on it to the last cent.
The read cap has been three different numbers this year
If you have researched this before and come away confused, here is why. The monthly post-read cap on pay-per-usage plans is not a contested figure between sources. It is a figure X has changed repeatedly without telling anyone.
| Date | What the page said |
|---|---|
| 22 January 2026 | No subscriptions, no monthly caps |
| 10 March 2026 | A monthly cap of 2 million post reads |
| 3 April 2026 | The cap sentence is absent entirely |
| By 6 September 2026 | Capped at 3 million post reads per monthly billing cycle |
No changelog entry announces any of those three changes, and no page on the documentation site carries a visible last-updated date. Articles quoting two million are not careless, they are quoting X's real text from earlier this year and have not gone back.
While the documentation says three million on four separate pages, X's own developer marketing site advertises consumption-based billing with, in its words, no monthly caps. Both were live on 8 September 2026. Budget against the documentation, not the marketing.
What actually happens when the money runs out
This is the part we can tell you that nobody else has written down, because we did not read it anywhere. It happened to us.
When a pay-per-usage balance reaches zero, the API returns HTTP 402 with a body identifying the problem type as credits-depleted and the detail as credits depleted. It blocks reads and writes alike. Waiting does not help, because it is not a throttle. Only adding credit clears it.
The status code 402 does not appear anywhere in X's published documentation. The documented status table lists 400, 401, 403, 404, 409, 429 and the server errors, and it describes 429 as covering rate limit or usage cap exceeded. A developer following the documentation would write a handler for 429 and never catch the failure that actually occurs.
The wording has already moved once. An earlier version of this failure said your enrolled account does not have any credits to fulfil this request. If you are matching on the prose, match on the problem type as well, because that is the stable identifier and the sentence is not.
‼️ The operational lesson cost us more than the credits did. Every user posts through one developer app, so a single depleted balance stops posting for everyone at once and no individual user can do anything about it. Worse, our scheduler treated the failure as the post's own fault and marked queued posts permanently failed. Topping the balance back up would not have recovered one of them. If you build on this, classify platform-side failures separately from content-side ones before you need to.
The controls around the balance have also failed in the other direction, which is worth knowing before you rely on them. One developer had a $400 spending cap set, unlimited spending switched off, and was charged $6,594.58 in a single billing cycle across thirty-one separate $200 auto-recharges. X confirmed an engineering bug and refunded everything above the initial transaction. Another reported a cap silently changing itself to unlimited. Auto-recharge has failed to fire at all for others, leaving balances at zero for hours.
None of that is a reason not to build on the API. It is a reason to watch the invoice rather than trust the cap, and to know that the support channel is a public forum where one staff member answers.
The old plans, and why they are not a fallback
A lot of advice still treats Basic and Pro as live options. They are not, and the wind-down is more recent and more forceful than most write-ups suggest.
- At the February 2026 launch of pay-per-usage, X explicitly said Basic and Pro remained available and that existing subscribers could opt in to the new model. The tiers were not closed that day.
- Basic was deprecated on 21 May 2026 and auto-migrated after 1 June.
- Pro was deprecated on 14 August 2026 and auto-migrated after 1 September, which is to say it has just happened.
- X's wording on the migration is that opting out means losing API access, and that the migration is final and cannot be reversed.
As a yardstick, archived pricing pages and X's own announcements show what those plans bought. Basic launched in March 2023 at $100 a month with 50,000 app-level writes and a 10,000 read cap. In October 2024 X raised it to $200 and lifted the read cap to 15,000. Pro, which arrived separately in May 2023, was $5,000 a month for 300,000 writes and one million reads. So Basic's price doubled while its read allowance rose by half, which is a real-terms increase rather than the flat one it is sometimes described as.
There is also a category of write you can no longer buy at any price. Following, likes and quote-posts through the API were removed from all self-serve access in April 2026. If you are planning an engagement tool, that is not a budgeting question, it is a feasibility one. The rate limits page still lists those endpoints, which is one of several places the documentation contradicts itself.
Can you just use something cheaper?
Quick answer
Not for posting. Every third-party Twitter data provider is read-only. None of them publishes a create-post endpoint, so the link surcharge has no workaround. They compete on reading, where they are genuinely far cheaper, and they carry a different kind of risk instead of a bill.
This is the obvious next question after a rate card, so it is worth answering plainly. The cheaper providers solve a different problem from the one a publishing tool has. They sell reads, at rates that make X's look eccentric, and not one of them will publish a post for you. Posting has exactly one route, and it is the metered one described above.
Two things are worth knowing before treating the reading side as free money.
- X's terms carry a liquidated damages clause. Requesting, viewing or accessing more than one million posts in any 24 hour period is priced in the terms of service at $15,000 per million. The same section reaches anyone who induces or knowingly facilitates it, which is how X gets at providers rather than only their customers.
- Enforcement is current, not historical. On 24 August 2026, two weeks before this article, X sent a cease and desist to the open source Nitter project alleging circumvention of its API and misuse of session tokens. The main instance went offline. The project said in September it intends to continue after taking legal advice.
So the honest framing is not that the cheap routes are a trick. It is that they buy you reading, they do not touch your posting bill at all, and the money you save is exchanged for a dependency that can be switched off by a letter. We went through the equivalent judgement on the other platform in will a LinkedIn MCP get your account restricted.
How this compares to everywhere else
It is worth knowing whether Twitter is unusual here or whether this is simply what social APIs cost now. It is unusual.
| Platform | Fee to post | The real barrier |
|---|---|---|
| Yes, per post, more with a link | Cost | |
| Bluesky | No | None, open registration |
| Mastodon | No | None, self-registering |
| Threads | No published fee | Meta app review |
| No published fee | The hardest approval of the set | |
| Free below a threshold | Commercial use needs a contract | |
| Discord | No published fee | Verification past 100 servers |
Stated precisely, and this is the version that survives scrutiny: Twitter is the only one of these that charges a monetary price per post at ordinary publishing volume. Reddit charges above a threshold and gates commercial use behind a contract. Telegram publishes a per-message price only above about 30 messages a second, which no publishing tool approaches. LinkedIn charges nothing and is the hardest of all to get into, which we went through in does LinkedIn have an analytics API.
So the platforms sort into two kinds of wall. Twitter's wall is priced and you can see it. LinkedIn's is an approval process and you cannot. Which one is worse depends entirely on whether you have a company and a budget or neither.
What this means if you are building on it
- Model the URL rate as your default, not the exception. If your users share links, and creators do, $0.200 is your real per-post cost.
- Count media as extra post creations, because they are, whatever the pricing page says today.
- Read your own data through the owned-reads endpoints. It is the cheapest correct decision available and it is one line.
- Handle 402 explicitly and separately from 429, and match the problem type rather than the sentence.
- Separate platform failures from content failures in whatever posts on a schedule, before a depleted balance teaches you the difference.
- Re-check the rate card on a schedule. It changed in October 2025, February, April, May and August 2026, and the cap moved silently at least twice.
Does X's own MCP server bill against the same meter?
Quick answer
Yes. X's hosted MCP server at api.x.com bills the authenticated user through the same pay-per-usage account, and returns the same 402 when credits run out. There is no separate MCP subscription, no MCP rate card and no free allowance. What X has never published is which line item each MCP tool maps to.
The proof is in X's own error payload rather than its documentation. Connecting without enrolment returns a reason of user-not-enrolled, a required enrolment of pay-per-use, and the plain sentence that the request is billed to the authenticated user. Staff confirmed the same in the forum. The word MCP does not appear on the pricing page at all.
‼️ The hosted server cannot create an ordinary post. Its only writes are bookmark changes and publishing an Article. If you connect an assistant to it expecting to schedule posts, that is not a permissions problem you can fix, it is the server's scope. The separate self-hosted server X published in February does expose post creation, and has not been updated since April.
That matters for anyone wiring an assistant to Twitter, which is what our own MCP connector does. It also means the cost questions in this article apply to agent workflows exactly as they apply to a scheduler, because underneath they are the same metered calls.
The case for the pricing, which is better than it sounds
It would be easy to end this as a complaint, and that would be one-sided. X's own answer to the criticism is worth granting.
Under the old model the entry price for any serious access was $200 a month whether you used it or not. Under pay-per-usage a hobbyist posting a few plain text posts a day pays cents, and endpoints that were locked behind tier restrictions are now reachable by anyone with a balance. X argues this made the API more accessible to developers who could never afford a fixed subscription, and for that group it plainly did. One of the developers we quoted above returned three months later to say he had made his peace with it by passing the cost through to his customers.
The complaint that survives is narrower and fairer: not that metering is wrong, but that the meter is documented in pieces, changes without announcement, and charges the most for the thing publishers most need to do.
Where we sit with this
We post to Twitter through the official API and we pay these rates, including the URL rate, which applies to a large share of what creators actually schedule. We do not use the following, likes or quote-post endpoints, so April's removals did not affect us, but that was luck as much as design.
Our MCP connector is where the posting and reading tools live if you want an assistant driving this. If you would rather not connect an account at all, our Claude skills are plain files that hold no credentials and call no API, so they cost nothing to run and cannot be affected by any of the above.
The other platform in our world has the opposite shape of problem: nothing to pay and almost no way in. We covered the terms side of that in will a LinkedIn MCP get your account restricted, and the browser-tooling question generally in the Chrome extensions round-up for Twitter creators.
The honest summary of X's pricing is not that it is expensive. It is that it is knowable only in parts, changes without notice, and hides its most expensive behaviours in places the pricing page does not cover. You can build on it. You should just do the arithmetic yourself, and do it again next quarter.