What Does It Cost to Post to X Through the API? Someone Finally Published the Per-Request Numbers

Since February this has been the most consequential unpriced cost in social media tooling: what does one post to X actually cost the tool that sends it?

Almost nobody publishes it. As of 2026-09-15, one vendor does.

The numbers

Zernio's pricing page states:

"X charges per API call on their end. We pass those costs through at X's exact rates with zero markup."

With the range given as approximately:

It also notes that "Analytics and inbox sync for X accounts are opt-in" — which is itself informative: polling for analytics is a read, and reads cost money, so a vendor passing costs through has a reason to let you turn it off.

Two caveats on using these figures. They are one vendor's stated pass-through, not a quote from X's own price list; and they are a range rather than a rate card. Treat them as an order of magnitude you can plan with, not a contract.

Why a post with a link costs forty times a read

We are not going to guess at X's internal reasoning, but the practical effect is clear and worth internalising: the expensive action is the one you most want to automate.

Almost every commercial use of automated X posting involves a link — a blog post, a product, a video. That is precisely the request at the top of the range. Meanwhile the cheap action, reading, is what analytics dashboards do constantly in the background.

So the cost profile of a typical scheduler is the opposite of intuitive: a few hundred posts a month can cost less than continuous analytics polling across the same accounts, which is exactly why opt-in polling shows up as a feature.

Doing the arithmetic yourself

Using the published range, for a single account:

Now look at any scheduler charging $5 a channel per month and posting to X on your behalf. The maths only works because most users post far less than they think.

This is the real answer to "why do schedulers keep changing their X support". Since February, every vendor built on this API has faced the same options: raise prices, move X to a higher tier, drop X support, or pass the cost through. The fourth option is the newest one and the most transparent.

What this means for the three kinds of buyer

The third row is the one that surprises people who self-host to save money. Running your own scheduler means running on your own X credentials, and that meter bills you rather than a vendor. The other hidden cost of that path — app review time — is covered in this piece.

The way around it that is not a trick

There is one architecture where this cost does not exist, and it is worth naming plainly rather than pretending it is a loophole: content published through your own logged-in browser session does not make an API call, so there is no per-request charge.

That is not free — it costs a machine that stays on, and it requires pacing that does not look mechanical, because you are operating in the interface rather than through a sanctioned endpoint. It is the architecture NoobClaw uses (local fingerprint-isolated profiles, your own sessions, per-account content), and it is a genuinely different set of trade-offs rather than a strictly better one. Both are compared in API vs browser automation.

The wider question of who absorbs this cost across the category is traced in Who Is Paying for the X API Now?.

Four ways to spend less on the same output

If you are paying per request, these are the levers, roughly in order of how much they save:

1. Turn off polling you do not read

Analytics and inbox sync are reads, and reads run continuously in the background whether you look at the dashboard or not. A tool that lets you opt out of per-account polling is offering you the single biggest lever there is, because posting is bursty and polling is constant.

2. Reconsider the link

The published range puts posts containing URLs at the top. That does not mean never link — it means know that a link-bearing post is the expensive shape and decide deliberately rather than by habit. A thread where only one post carries the link costs less than one where every post does.

3. Batch reads instead of looping

If you are building the integration, one request that returns many items beats many requests returning one. This is obvious in principle and routinely violated in practice, usually by a loop written before anyone knew reads were billable.

4. Match your pricing model to your shape

Heavy, steady posting favours a flat per-channel price. Light posting across many accounts favours pass-through. Being on the wrong side of that line is more expensive than any micro-optimisation above it.

The cheapest request is the one you did not make. Most X API spend in this category is not posting — it is polling for data nobody opened.

One structural point to close on. This cost did not appear because anyone behaved badly; it appeared because a platform repriced access, and every layer downstream had to decide what to do about it. The useful habit going forward is to ask, of any tool, which of its costs are its own and which are passed through — because the passed-through ones can change without the vendor touching its price page, and you will feel it either as a price rise or as a feature quietly disappearing. The same question applied to the AI layer rather than the API layer is in this piece.

FAQ

Are these X's official prices?

They are one vendor's published pass-through rates, stated as being at X's exact rates with zero markup. They are not a quote from X's own price list, so use them as a planning order of magnitude and verify against current developer pricing before making a commitment.

Why does a post with a URL cost more than a plain post?

The published range distinguishes them; the reasoning is not something we are going to guess at. What matters operationally is that the action most commercial automation depends on sits at the top of the range.

Does this affect posting to X from the normal app?

No. This is developer API pricing. Posting from x.com or the mobile app does not consume API credits — which is exactly why the browser-session architecture avoids the cost.