The Unofficial X (Twitter) API in 2026: What It Does, and What the Official One Costs

Short on time? X's official API no longer has a free tier. It is pay-per-use, billed per resource returned, and the meter runs on your customers' curiosity rather than your revenue: $0.005 per post read, $0.010 per user, $0.200 to publish a post containing a link. An unofficial X API works differently. It authenticates your own account and calls the same internal endpoints x.com calls in the browser, so nothing is metered per call and nothing is restricted to what X currently sells. The trade is that you own the account risk and the maintenance. Commentify runs this as an unofficial X and LinkedIn API, and an MCP server for AI agents.

Most people building on X in 2026 arrive at the same wall. The idea is reasonable, the endpoints exist, and then the pricing page turns a $50/month product into a $900/month one. Worse, the cost is not fixed. It scales with how much your users search.

Here is what the official API actually costs at realistic volume, the three billing rules that make bills bigger than the rate card suggests, and what changes when you go around it.

What changed with the official X API

In early 2026 X replaced its subscription ladder with pay-per-usage. There is no Free tier, no $200 Basic and no $5,000 Pro to sign up for: the legacy plans are closed to new developers. You buy credits in the Developer Console upfront, and they are deducted in real time as you make calls.

On paper this is fairer, and for a hobby script it genuinely is. You can have a month with no usage and no cost. But two details change the economics for anything with customers in it:

• Reads are billed per resource returned, not per request. One search page of 100 posts is 100 billable reads, so that single call costs $0.50.
• Pay-per-use is capped at 3 million post reads per billing cycle, and there is no bigger plan to buy. Above the ceiling you are negotiating a custom Enterprise agreement, which is a sales cycle rather than a checkout.

The rate card that matters

X publishes prices for around thirty operations. These are the ones that decide whether a product is viable:

Prices move. X repriced mid-2026 and says so on the pricing page, so confirm current rates in the Developer Console before you plan a business around them.

Three rules that make the bill bigger

Reads are per item. This is the one that catches people. Any workload that discovers content, rather than fetching things it already has IDs for, pays in proportion to how much it looks at. Broad keyword monitoring is the most expensive thing you can build.

Links cost 13x. Creating a post is $0.015. Creating a post that contains a URL is $0.200. Every marketing tool on earth exists to post links, so this single line item is often the largest on the invoice.

Owned Reads almost certainly do not apply to you. The $0.001 rate looks like it solves everything, and for a personal analytics dashboard it does. But it only applies when the authenticated user is both the subject of the request and the owner of the developer app. The moment you have customers, none of their reads qualify. You are paying five to ten times the rate you budgeted from the docs.

One rule works in your favour: resources are deduplicated within a 24-hour UTC window, so reading the same post twice in a day is charged once. If your searches overlap heavily, real cost lands below naive multiplication.

What this costs at product scale

Take a single social-selling agent: ten keyword searches a day, roughly 700 unique posts after deduplication, 100 author lookups, and 20 replies. That is a modest workload for one person.

Two things stand out. The first is that per-seat cost is higher than most tools in this category charge per seat, before any margin. The second is the ceiling: at 700 unique reads per account per day, roughly 140 customers consume the entire 3 million read allowance. You do not grow out of pay-per-use gradually. You hit a wall and then start a procurement conversation.

What an unofficial X API does instead

An unofficial API gets no privileged access. It authenticates your X account with your own session and calls the internal GraphQL endpoints that x.com calls when you scroll, search, and reply. From X's side, the traffic is you using X.

That changes three things:

• Nothing is metered per call. Cost becomes a fixed per-connected-account number covering proxies and maintenance, rather than a meter that scales with how curious your users are. A given account costs the same whether it reads 100 posts a day or 5,000.
• The surface is what a person can do, not what X currently packages. Search, threads, profiles, replies, reactions, publishing, the inbox: if it is in the app, it is reachable.
• No credits, console, or approval step. You connect an account and start.

Be clear about what it is not. This is per-account access at human volume, so it does not replace Enterprise for firehose, filtered streams, or full-archive research. If you need 500 million posts for a dataset, buy the data. If you need one account to behave like an engaged, effective person, this is the right shape and the official API is not.

On our side the live X surface is deliberately narrow and honest: keyword and query search over the timeline, reading a post with its thread for context, and generating and publishing replies in your voice, executed on a schedule in our cloud with per-account daily caps and randomised pacing underneath. Same connection as LinkedIn, so you are not maintaining two integrations. The wider write surface is in progress rather than shipped, and we would rather say that than list it.

The part nobody warns you about

Building the first unofficial X call takes an afternoon. Keeping it working is the actual product, and X is meaningfully harder than LinkedIn here.

Every internal GraphQL call is addressed by a build-specific hash: /i/api/graphql/<queryId>/SearchTimeline. That hash changes when X ships, and each operation also carries its own list of feature switches and field toggles that have to match the current build or the request fails outright. A client that hardcodes them works until the next deploy.

So a working integration re-derives them from the JavaScript X actually shipped. Ours refreshes on a six-hour cron: fetch the app HTML, find the client bundles, and extract every queryId and operationName pair plus the per-operation feature metadata. Some writes additionally need a per-request transaction header derived from the same bundle.

Then X changes the bundle itself. In August 2026 it began serving a new Vite-built app on the homepage and profile pages, which no longer embeds the webpack runtime, so there were no query IDs to extract and nothing to resolve the transaction header against. Every naive scraper broke. The fix was unglamorous: parse /home, which still serves the legacy app, and carry on.

That is the honest argument for buying rather than building. Not that the calls are hard. That someone has to notice at 3am when a redesign silently empties your query ID cache.

Staying inside safe limits

Cost is the reason people leave the official API. Account safety is the reason they come back if the unofficial route is done badly.

X suspensions follow volume, rhythm, duplicated text, and inconsistent location, not specific endpoints. What keeps accounts healthy is unexciting: per-account daily caps, randomised gaps rather than fixed intervals, activity inside plausible waking hours, unique text on every reply, a residential IP that matches where the account normally logs in, and stopping the account immediately on the first warning instead of retrying.

The structural point matters more than any individual number: those limits belong below the API, enforced server-side per connected account. Limits in your application code are advisory. Limits in a prompt you hand to a language model are decoration. We went through this in more detail for the unofficial LinkedIn API, and the reasoning transfers directly.

API or MCP?

Same capabilities, two ways to reach them, and the right one depends on who is calling.

• Choose the REST API if you are embedding X into your own product and want to own retries, storage, webhooks, and the interface.
• Choose MCP if you want an AI agent doing the work directly. Connect Claude, Cursor, or ChatGPT once and ask in plain language: find posts worth replying to, read the thread, draft something in my voice, post it. No integration code. Our guide to the MCP server covers that path, including the catch that MCP alone stops running the moment you close your laptop.

Frequently asked questions

Is there an unofficial X (Twitter) API?

Yes. An unofficial X API authenticates your own account and calls the same internal GraphQL endpoints x.com calls in the browser, which means it is not metered per call and is not limited to what the official API sells.

Is the X API still free?

No. X replaced its subscription tiers with pay-per-usage in early 2026 and removed the free tier. You buy credits upfront and they are deducted per resource read or per write request, with no monthly minimum but also no free allowance.

How much does the X API cost per call?

Reads are billed per resource returned rather than per request: $0.005 for a post, $0.010 for a user, $0.010 for a DM event. Writes are billed per request: $0.015 to create a post, $0.200 to create a post containing a URL. Rates change, so confirm them in the Developer Console before planning against them.

Why is my X API bill higher than expected?

Usually one of three things. Reads are charged per item returned, so a single search page of 100 posts costs 100 reads. Posts containing a link cost about 13 times a plain post. And the cheap Owned Read rate only applies to your own data when you own the developer app, so every read you make on behalf of a customer is billed at the full rate.

Is there a limit on the X pay-per-use plan?

Yes. Pay-per-usage is capped at 3 million post reads per billing cycle, and there is no larger plan to buy above it. Beyond that ceiling you have to negotiate a custom Enterprise agreement, which is a sales cycle rather than a checkout.

Can an AI agent reply to posts on X for me?

Yes. With an MCP server connected to Claude, Cursor, or ChatGPT, the agent can search for relevant posts, read the thread for context, draft a reply in your voice, and post it, subject to per-account daily caps and pacing enforced below the tools.

Will my X account get suspended?

That is the real risk to manage rather than a certainty. Suspensions follow volume, unnatural timing, duplicate text, and inconsistent locations. Daily caps, randomised pacing, a residential IP that matches the account, unique text per reply, and stopping on the first warning are what keep accounts healthy.

The bottom line: the official X API is now a meter, and it is priced for data buyers rather than for products that help one account participate well. An unofficial API turns that variable cost into a fixed per-account one and removes the ceiling, in exchange for account risk you manage with pacing and maintenance someone has to own. See the capability list and pricing.