X API pricing: what each call costs on pay-per-use

Credits are bought in advance in the Developer Console. Each call deducts its price in real time, and the console shows usage and the remaining balance live. Reads are charged per resource in the response, so a request that returns 100 posts is charged for 100 posts. Writes and actions are charged per request.

• Spending limit. You can set a maximum spend per billing cycle. When it is reached, requests are blocked until the next cycle.
• Auto-recharge. Optional. It tops the balance up when it falls below a threshold you choose, at most once every five minutes, and pauses if the balance reaches zero.
• Read cap. Pay-per-use accounts are capped at 3 million post reads per monthly billing cycle. Past that, X points you to an Enterprise plan.
• Rates can change. X states that prices are subject to change and that the Developer Console always shows the current ones. Check it before you build a business model on a number.

As listed on X's pricing page on 2026-10-26. Each price applies to every resource returned in a response.

The expensive reads are people, not posts. Loading a follower list costs $0.010 for every account in it, so a feature that fetches a thousand followers spends $10 on one call. Posts are half that per item, and likes, mutes and blocks are a tenth.

As listed on X's pricing page on 2026-10-26. Each price applies once per request.

X prices owned reads at $0.001 per resource, a fifth of a normal post read. They cover a user's own posts, mentions, likes, bookmarks, followers, following, blocks, mutes and lists, through endpoints such as GET /2/users/{id}/tweets and GET /2/users/{id}/followers.

The catch is in the condition. The pricing page says the owned rate applies when the {id} in the request matches the authenticated user and that user is the owner of the developer app. A personal dashboard you build for your own account qualifies. A product where many people sign in and read their own data does not, because they are not the owner of your developer app, so those reads are charged at the normal rates in the table above.

• Every billable resource is deduplicated within a UTC day. Request a post you were already charged for today and the second request is free.
• The window resets at midnight UTC, not at midnight where your users are.
• It applies to all billable resources: posts, users and the rest.
• X says it is not absolute. It happens in the vast majority of cases, but edge cases such as outages can mean a resource is charged twice.

In practice this rewards apps that refresh the same data once a day and punishes apps that spread reads of new data across many requests. Reading a user's last fifty posts four times in one UTC day costs the same as reading them once. Reading them once a day for thirty days costs thirty times as much.

Worked out from the listed rates, at standard (not owned) prices. They are arithmetic, not measurements, and they ignore deduplication savings within a day.

The pattern: writes without links are cheap, people are expensive to read in bulk, and anything that refreshes daily multiplies by thirty. BuzzyX runs on these prices; what the X API costs, and why BuzzyX has daily limits shows how they turned into per-day caps on one real product.

1. 01Set a spending limit in the Developer Console before you ship anything. A bug that loops on a read endpoint is the most common way to burn credits.
2. 02Cache what you read in your own database and serve repeat views from it. Never call X on a plain page view if the data can be a few hours old.
3. 03Batch refreshes into one pass per UTC day, so deduplication works for you rather than against you.
4. 04Count link posts separately. If users schedule posts with URLs, price your product with the $0.200 rate, not the $0.015 one.
5. 05Avoid bulk follower and following reads unless the feature needs every account. Sample, or let the user ask for it.
6. 06Re-check the rates in the Developer Console every month. Your margin depends on a page that can change.