# X API Alternative: What 1,000 Posts Cost on X Pay-Per-Use vs EveryInfra

> X API reads cost $0.005 per post and $0.010 per user. We priced 1,000 posts, followers, and replies with 27 live calls, and show when X costs less.

- Canonical page: https://everyinfra.com/en/blog/x-api-alternative
- Published: 2026-11-09T03:19:00+08:00 · Fact-checked: 2026-11-09T01:30:00+08:00

The X API now sells read access only on pay-per-use terms. One post costs $0.005 and one user profile costs $0.010, so 1,000 posts cost $5. We read this on the [X pricing page](https://docs.x.com/x-api/getting-started/pricing) on November 9, 2026, at 00:15 Singapore time. On the same day we made 27 live calls to EveryInfra with `twitter/search` and 8 other capabilities. We pay one price per call, and a search call returns up to 200 posts.

In our test, 1,000 posts from keyword search cost $0.0033, about 1/1,530 of the X price. A second change matters even more. On [October 23, 2026](https://devcommunity.x.com/t/inform-x-api-ppu-expansions-update/279110), X said that author objects returned through expansions will cost $0.010 each from November 22. Our first sample had 186 different authors in 200 posts. At that rate, 1,000 posts with author data will cost about $14.30 on X instead of $5.

> **Key points**
>
> - X pay-per-use: $0.005 per post, $0.010 per user, $0.010 per follower or following entry, and $0.010 per trends request. The cap is 3 million post reads per month.
> - From November 22, X bills users, media, and quoted posts that come back through expansions. With our measured author ratio, 1,000 posts with authors cost about $14.30.
> - EveryInfra bills per call. `twitter/search` costs $0.000556 per call and returns up to 200 posts. Our 27 live calls cost $0.010008 in total, and the 9 calls that were empty, invalid, rate-limited, unauthenticated, or hit a 503 cost $0.
> - The opposite case is also true. If you poll one query every 15 minutes and fewer than about 10.7 new posts appear per day, X's 24-hour deduplication costs less.
> - Use the official X API to post, send DMs, stream in real time, count posts, or read your own account. Use the route in this article only for public read-only data at volume.

![Illustration of a mail sorting desk with two balance scales. The left scale is dark grey. One pan holds a single envelope with a small name tag clipped to it, and the other pan holds a tall stack of coins. Next to it, a pile of envelopes, each with its own tag, waits to be weighed. The right scale is teal. One pan holds a whole bundle of envelopes tied with a teal ribbon, and the other pan holds only one coin.](https://everyinfra.com/articles/x-api-alternative/img-explain.webp)

X charges for each object it returns, so posts and authors are separate charges. EveryInfra charges per call, so one request costs the same for any number of items.

This article is for developers who look for an alternative to the X API because a read-only project costs too much on the official API. Typical projects are brand monitoring, newsroom alerts, public-health listening, research samples, and data feeds for AI agents. On our side, every number comes from live calls on November 9, 2026, and we kept each raw response. On the X side, we used only public material: the X developer docs, forum announcements from the X Developer Platform team, and the X changelog. We did not open an X developer account and we did not call the X API. All X numbers in this article are list prices multiplied out, not real invoices.

We already have an article that compares tweet scrapers by price per result. In that article, the official X API has one short section. This article turns it around and puts the X billing rules in the center. We cover the price per endpoint, the 24-hour deduplication rule, and the November 22 expansion change. We also cover the monthly cap, free credits, setup steps, and MCP. It also lists the cases where you should stay on the official API.

## The short answer: x api alternative cost table

The table puts seven common read-only data types on one unit: 1,000 items (posts, accounts, or replies) or 1,000 requests (trends and single-post lookups). The X column is the public unit price from [docs.x.com](https://docs.x.com/x-api/getting-started/pricing) times 1,000. The EveryInfra column uses our live calls. We divide the amount we were actually charged (`billing.charged_usd` in each response) by the number of unique items, then multiply by 1,000.

| Data | X API per 1,000 | EveryInfra per 1,000 (measured) | Our capability | Same product on both sides? |
| --- | --- | --- | --- | --- |
| Posts from keyword search | $5.00 | $0.00327 | `twitter/search` | Yes; our default sort is "top", see Test 1 |
| Posts plus author (from Nov 22) | $14.30 | $0.00327 | `twitter/search` | Mostly; 2 of our 9 searches had no author fields |
| Posts from one account | $5.00 | $0.00278 | `twitter/user_posts` | Yes; we return up to 200, X goes back up to 3,200 |
| Profiles, one per call | $10.00 | $0.556 | `twitter/profile` | Yes |
| Profiles by ID, batch (no follower counts) | $10.00 | 503 on 3 tries, not measured (catalog estimate $0.0403) | `twitter/profiles_by_ids` | No; ours has no bio and no follower counts |
| Followers list | $10.00 | $0.000278 | `twitter/followers_list` | No; X gives the full list, we give a sample of visible followers |
| Replies under one post | $5.00 | $0.0115 | `twitter/comments` | No; we return up to 50 and cannot page |
| Trends (per 1,000 requests) | $10.00 | $0.556 | `twitter/trending` | Yes |
| Single post by ID (per 1,000 posts) | $5.00 | $0.556 | `twitter/post` | Yes; X takes 100 IDs per call |

![Grouped horizontal bar chart on a log scale, each grid line is 10 times: the cost of 1,000 items on the X API and on EveryInfra (measured). Keyword search: $5 vs $0.00327. Posts plus author: $14.30 vs $0.00327. Posts from one account: $5 vs $0.00278. Profiles one by one: $10 vs $0.556. Followers list: $10 vs $0.000278. Replies: $5 vs $0.0115. Trends per 1,000 calls: $10 vs $0.556. Single post by ID: $5 vs $0.556. Batch profiles by ID returned 503 on all three tries that day, so the chart has no bar for it. In each group, the grey bar is X and the teal bar is EveryInfra.](https://everyinfra.com/articles/x-api-alternative/fig-03-per-1k-bar.en.light.svg)

Read the table with three points in mind. First, the largest gaps come from full pages. A search or timeline call returns up to 200 posts, and a followers call returns up to 2,000 accounts. A fuller page spreads one call price over more items. When a request can return only one object, such as one profile or one post, the gap falls to 9 to 18 times. Second, the "posts plus author" row uses the X rules that start on November 22.

We used the author ratio from our first search (186 different authors in 200 posts). If the same authors post many times in your query, that row moves closer to $5. Third, X has a rule that we do not have. X charges for an object only once per UTC day, even if you read it many times. For a job that polls the same query and mostly sees old posts, the table overstates the gap. The deduplication section below shows when X costs less.

## How X API pricing works now

X launched pay-per-use for its developer API on [February 6, 2026](https://devcommunity.x.com/t/announcing-the-launch-of-x-api-pay-per-use-pricing/256476). You buy credits first, and each call deducts credits by endpoint. On [May 21](https://devcommunity.x.com/t/important-update-legacy-x-api-basic-plans-are-moving-to-pay-per-use-ppu/266305), X announced that legacy Basic plans will move to pay-per-use after June 1, each at its own billing date. Monthly Basic users get a $200 first credit charge at the move, and a default spend cap of $400 per billing cycle. On [August 14](https://devcommunity.x.com/t/important-update-legacy-x-api-pro-plans-are-moving-to-pay-per-use-ppu/273255), X announced the same move for Pro after September 1. Monthly Pro users get a $5,000 first credit charge and a default spend cap of $10,000. Today, pay-per-use is the only self-serve option for new developers. Higher volume needs the [Enterprise interest form](https://docs.x.com/forms/enterprise-api-interest), and the price is not public.

The screenshot shows the "Read operations" part of the pricing page. We opened it on November 9, 2026, at 00:20 Singapore time in a headless browser. The teal box marks the read prices and the note about the cap of 3 million post reads per month. All X math in this article starts from this box.

![Screenshot of the Read operations section of the X API pricing page on docs.x.com. A teal box marks the full table and the note below it. Posts Read costs $0.005 per resource, User Read $0.010, DM Event Read $0.010, Following/Followers Read $0.010, List, Space, Community, and Note Read $0.005 each, Like, Mute, and Block Read $0.001 each, and Profile Update Read $0.005. The note says that pay-per-usage plans are capped at 3 million Post reads per monthly billing cycle, and that higher volume needs an Enterprise plan.](https://everyinfra.com/articles/x-api-alternative/img-shot-x-pricing.webp)

X pricing page: reads are billed per returned object, with a cap of 3 million posts per month. Screenshot taken Nov 9, 2026. [docs.x.com pricing page screenshot](https://docs.x.com/x-api/getting-started/pricing)

| X resource or action | Unit price | Billing unit | What it means for a read-only project |
| --- | --- | --- | --- |
| Posts: Read | $0.005 | each post returned | Search, timelines, post lookup, and filtered stream all use it |
| User: Read | $0.010 | each user returned | Profile lookup, and author expansions from Nov 22 |
| Following/Followers: Read | $0.010 | each account returned | Follower and following lists |
| List / Space / Community / Note: Read | $0.005 | each object | Lists, Spaces, Communities, Community Notes |
| Like / Mute / Block: Read | $0.001 | each object | Liking users and similar lists |
| Owned Reads | $0.001 | each object | Since Apr 20, 2026, only when the app owner reads their own data |
| Counts: Recent / All | $0.005 / $0.010 | each request | Post counts without the posts |
| Trends | $0.010 | each request | Trending topics |
| Post: Create | $0.015 | each request | One normal post |
| Post: Create (with URL) | $0.200 | each request | A post that contains a link |

Two points in this table are easy to miss. First, X bills reads per returned object. Your X cost grows in direct proportion to the number of items, and a full page does not make an item cheaper. Recent search returns at most 100 posts per page, and full-archive search returns at most 500. Second, the page says that prices can change and that the [Developer Console](https://console.x.com) shows the current rates. The April 20 change raised a normal post from $0.01 to $0.015 and set posts with links at $0.20 ([April 16 announcement](https://devcommunity.x.com/t/x-api-pricing-update-owned-reads-now-0-001-other-changes-effective-april-20-2026/263025)). If your budget is tight, read the pricing page again each month.

## From November 22, X bills expansion objects

X API v2 has a feature called expansions. When you add `expansions=author_id` to a post request, the `includes` part of the response carries the full author object. So you do not need a second user lookup ([expansions docs](https://docs.x.com/x-api/fundamentals/expansions)). Until November 21, these extra objects do not count toward usage.

The X Developer Platform team posted an [announcement on October 23](https://devcommunity.x.com/t/inform-x-api-ppu-expansions-update/279110). From November 22, expansions that return posts, users, media, polls, or places cost the standard rate for each resource. The rates are $0.005 per post, $0.010 per user, $0.005 per media object, $0.005 per poll, and $0.005 per place. The team also wrote that this is not a new pricing model, but heavy use of expansions can change your spend.

This change hits monitoring projects hard, because almost nobody wants post text without the author. We used our first search to estimate the effect. `twitter/search` for "x api pricing" returned 200 posts from 186 different authors (by `author_id`). Suppose you get the same 200 posts from the X search endpoint with the `author_id` expansion after November 22. The bill is 200 × $0.005 + 186 × $0.010 = $2.86.

That is about $14.30 per 1,000 posts, or 2.86 times the old $5. If you also expand `attachments.media_keys`, add $0.005 for each media object. In this sample, 78 of the 200 posts had an image or a video. X deduplicates user objects per UTC day too, so an author who appears many times in one day costs $0.010 only once. Queries that return a few fixed accounts will rise much less.

| Same 200 posts for "x api pricing" | Until Nov 21 | From Nov 22 | EveryInfra (measured) |
| --- | --- | --- | --- |
| Posts | $1.00 | $1.00 | $0.000556 (one call) |
| Author objects (186 different authors) | $0 (expansions not billed) | $1.86 | Included: `author_follower_count`, `author_is_verified`, and more in each post |
| Total | $1.00 | $2.86 | $0.000556 |
| Per 1,000 posts | $5.00 | $14.30 | $0.00278 (this one full page of 200; the $0.00327 in the main table is the average of all 9 searches, with two pages of 100) |

Our response already puts author fields in each post: follower count, verified status, bio, and account creation date. The catalog lists 38 `response_fields` for `twitter/search` ([catalog](https://api.everyinfra.com/api/v1/social/catalog)). This does not mean that the two sides return the same fields. The X post object has edit history, context annotations, and other fields that we do not return. The fields section below shows the differences one by one.

## How we tested, and how we decided what counts

Before the tests, we wrote down our pass and fail rules. We needed at least four data types, each with one or more live calls, at three or more different times. The price per 1,000 items always uses the amount charged divided by unique items, not the `limit` in the request. We needed at least two calls that returned no data, with their charge recorded. If X was cheaper or better in any case, the text and the table had to say so.

All requests went to `POST https://api.everyinfra.com/api/v1/social`, and the key came only from an environment variable. For each call we logged the send time, HTTP status, client-side total time, item count, and `charged_usd`. A script then computed every number in the text, tables, and charts from the raw responses.

| Data | Capability | Calls | Time (Singapore time) | What we checked |
| --- | --- | --- | --- | --- |
| Keyword search | `twitter/search` | 9 | 00:17–00:40 | Items per call, overlap, date range |
| Account posts | `twitter/user_posts` | 3 | 00:18, 00:24, 00:39 | How far back one call goes |
| Profiles | `twitter/profile`, `twitter/profiles_by_ids`, `twitter/search_users` | 6 | 00:29–01:48 | Single and batch cost |
| Followers | `twitter/followers_list` | 1 | 00:23 | Accounts per call |
| Replies | `twitter/comments` | 2 | 00:30, 00:31 | Replies per call |
| Trends and single post | `twitter/trending`, `twitter/post` | 2 | 00:25, 00:31 | Per-request pricing on both sides |
| Failures and empty results | missing account, wrong parameter, no key, rate limit (5 more 503 calls are in the rows above) | 4 | 00:21–00:27 | Charged or not |

All calls ran on November 9, 2026, between 00:17–01:48 Singapore time. There were 27 calls in total, 18 of them were charged, and the total charge was $0.010008. Several drafts shared the test key, which allows 10 calls per minute, so some calls hit the rate limit. We report those calls too.

## Test 1: keyword search, the same 1,000 posts

Post search is the most common use in read-only projects. X has two search endpoints. Recent search, `/2/tweets/search/recent`, covers the last 7 days, is open to all developers, and returns up to 100 posts per page. Full-archive search, `/2/tweets/search/all`, is open to pay-per-use and Enterprise accounts and goes back to 2006. It returns up to 500 posts per page and allows 1 request per second ([search docs](https://docs.x.com/x-api/posts/search/introduction), [rate limits](https://docs.x.com/x-api/fundamentals/rate-limits)).

Both endpoints cost $0.005 per returned post. Our match is [`twitter/search`](/en/twitter-api/search). It needs `keyword` and accepts `limit` (25 by default, 200 at most) and `sort`. You write X search operators such as `from:`, `since:`, and `lang:` inside `keyword`.

```bash
# Nov 9, 2026, 00:17:15 SGT: HTTP 200, 52.7 s, count 200, billing.charged_usd 0.000556
curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform":"twitter","action":"search","params":{"keyword":"x api pricing","limit":200}}'
```

The 9 successful searches returned 1,531 posts, with no duplicates inside any call. Seven calls returned the full 200. Call s05 returned 131 because the range `from:XDevelopers since:2026-01-01` gave only that many. The median of unique posts per call was 200. Two calls did not behave like the others, and we report them as they are. Call s02 at 00:24 and call s03 at 00:25 asked for 200 but returned 100. Each post in those two calls had only 15 fields, with no author ID, no author follower count, and no media. The other 7 calls had 26 to 32 fields per post.

The price was still $0.000556 per call, so those two calls cost $0.00556 per 1,000 posts. That is twice the full-page price, but still about 1/900 of X. The median time for the 9 searches was 54.1 seconds, and the slowest took 69.5 seconds. That misses our 30-second target, which we set before the test. Full 200-post calls took 48 to 59 seconds. If your program cannot wait, add `"mode":"async"` to the request body. You get a `job_id` at once and then poll for the result, as the `async_hint` field in the response says.

| Call | Time (SGT) | keyword | Returned | Unique | Post dates | Time | Charged |
| --- | --- | --- | --- | --- | --- | --- | --- |
| s01 | 00:17:15 | x api pricing | 200 | 200 | 2023-08-09 to 2026-11-08 | 52.7 s | $0.000556 |
| s02 | 00:24:21 | openai (`sort: latest`) | 100 | 100 | Nov 8, 16:09–16:24 UTC, within 14 min | 20.8 s | $0.000556 |
| s03 | 00:25:45 | inteligencia artificial lang:es | 100 | 100 | 2026-10-31 to 2026-11-08 | 69.5 s | $0.000556 |
| s01b | 00:29:40 | x api pricing | 200 | 200 | 2023-08-09 to 2026-11-08 | 56.5 s | $0.000556 |
| s04 | 00:32:00 | measles outbreak | 200 | 200 | 2016-07-11 to 2026-11-08 | 59.1 s | $0.000556 |
| s05 | 00:33:07 | from:XDevelopers since:2026-01-01 | 131 | 131 | 2026-01-06 to 2026-11-06 | 42.6 s | $0.000556 |
| s01c | 00:38:02 | x api pricing | 200 | 200 | 2023-08-09 to 2026-11-08 | 54.1 s | $0.000556 |
| s06 | 00:39:51 | dengue lang:es | 200 | 200 | 2020-05-25 to 2026-11-08 | 48.7 s | $0.000556 |
| s07 | 00:40:47 | Chinese term for "large model", lang:zh | 200 | 200 | 2026-05-01 to 2026-11-08 | 58.3 s | $0.000556 |

One result needs a separate note. The default sort is "Top". In the first "x api pricing" search, only 80 of 200 posts were from the last 7 days. Only 87 were from the last 30 days, and the oldest was from August 2023. X recent search cannot return the other 120 posts.

You need full-archive search for them. The price per post is the same, but the rate limit drops from 450 requests per 15 minutes to 1 request per second. In the other direction, if you want only the last 7 days on our side, add a `since:` date to `keyword`. Without it, old posts can appear, which is different from the default behavior of X recent search.

![Horizontal bar chart: items returned and unique items for each successful live call in this article. The followers list returned 2,000 accounts in one call, the most. Of the 9 searches, 7 returned the full 200, s05 returned 131, and s02 and s03 returned 100 each. The 3 account-post calls returned 200 each. The two reply calls returned 47 and 50. Trends returned 51. The single profile and the single post returned 1 each. In each call, returned items and unique items were the same.](https://everyinfra.com/articles/x-api-alternative/fig-06-count-bar.en.light.svg)

![Scatter chart of the client-side total time in seconds for each of the 18 charged calls in this article, grouped by capability. A short line marks the median of each group: keyword search 54.1 seconds, account posts 30.1, followers list 28.4, replies 10.9, single post 10.8, trends 10.5, and profile 8.8. The median of all 18 calls is 30.3 seconds. Profiles, single posts, trends, and replies took 9 to 12 seconds. Searches that returned 200 posts took 42 to 70 seconds, and the slowest took 69.5 seconds. The followers list of 2,000 accounts took 28.4 seconds.](https://everyinfra.com/articles/x-api-alternative/fig-07-latency-scatter.en.light.svg)

| Capability | Charged calls | Median time | Fastest | Slowest |
| --- | --- | --- | --- | --- |
| `twitter/search` | 9 | 54.1 s | 20.8 s | 69.5 s |
| `twitter/user_posts` | 3 | 30.1 s | 25.5 s | 30.4 s |
| `twitter/followers_list` | 1 | 28.4 s | 28.4 s | 28.4 s |
| `twitter/comments` | 2 | 10.9 s | 10.1 s | 11.6 s |
| `twitter/post` | 1 | 10.8 s | 10.8 s | 10.8 s |
| `twitter/trending` | 1 | 10.5 s | 10.5 s | 10.5 s |
| `twitter/profile` | 1 | 8.8 s | 8.8 s | 8.8 s |

## Test 2: posts from one account, and the 3,200 limit

For one account's posts, X uses the user timeline endpoint `/2/users/:id/tweets`. It returns up to the 3,200 most recent posts, can exclude replies and reposts, and costs $0.005 per post ([timelines docs](https://docs.x.com/x-api/posts/timelines/introduction)). The app-level rate limit is wide, at 10,000 requests per 15 minutes. One exception matters. When the app owner reads their own timeline, Owned Reads pricing applies from April 20, at $0.001 per post. That cheap route exists only on X.

Our match is [`twitter/user_posts`](/en/twitter-api/user_posts). It needs `username`, and `limit` goes up to 200. At 00:18 Singapore time we read @XDevelopers and got 200 posts, all unique, from November 19, 2025, to November 6, 2026. Of these, 120 were reposts and 55 were replies. At 00:24 we read @NASA and got 200 posts from September 23 to November 8, 2026, with 62 reposts. Each call cost $0.000556, which is $0.00278 per 1,000 posts.

The same 400 posts cost $2.00 on X. On X you can send `exclude=retweets,replies` and pay only for original posts. On our side we return everything and you filter by `is_repost` and `is_reply`. The price stays the same, but you keep fewer posts. In the 200 posts from @XDevelopers, 120 were reposts and 55 were replies, so only 25 were original. If you want only original posts, multiply our cost per post by 8. If you drop only reposts and keep replies, multiply by 2.5. For @NASA, 83 of 200 were original, so the factor is about 2.4. Before you price original posts per 1,000, look at how the account posts. Then choose one full `user_posts` call, or search with `from:` and date ranges.

To go back further than 200 posts, you can search with `from:` plus `since:` or `until:` and move back in time slices. We tested this once. At 00:33 we searched `from:XDevelopers since:2026-01-01` and got 131 posts in one call, from January 6 to November 6, 2026. Of these, 105 were reposts and 6 were replies, and the call cost $0.000556. We compared it with the `twitter/user_posts` call at 00:18.

All 131 posts were also in that set of 200, but that set had 180 posts from 2026. So the search slice missed 49 posts. Time slices work and cost the same low price, but they do not guarantee every post. The X timeline endpoint returns up to 3,200 posts in full time order, which is an advantage when you need a complete set. At 00:39 we read the same 200 posts from @XDevelopers again (call u01b), and the result was identical to the call at 00:18.

| Call | Time (SGT) | Capability and input | Items | Date range | Reposts | Replies | Charged |
| --- | --- | --- | --- | --- | --- | --- | --- |
| u01 | 00:18:16 | `twitter/user_posts`, @XDevelopers | 200 | 2025-11-19 to 2026-11-06 | 120 | 55 | $0.000556 |
| u02 | 00:24:51 | `twitter/user_posts`, @NASA | 200 | 2026-09-23 to 2026-11-08 | 62 | 55 | $0.000556 |
| s05 | 00:33:07 | `twitter/search`, `from:XDevelopers since:2026-01-01` | 131 | 2026-01-06 to 2026-11-06 | 105 | 6 | $0.000556 |
| u01b | 00:39:13 | Same as u01 | 200 | The same 200 posts as u01 | 120 | 55 | $0.000556 |

## Test 3: profiles and followers

X charges twice as much for user objects as for posts. User: Read and Following/Followers: Read both cost $0.010 each ([pricing page](https://docs.x.com/x-api/getting-started/pricing)). The `/2/users/by` lookup takes up to 100 usernames per call ([user lookup docs](https://docs.x.com/x-api/users/lookup/introduction)). The followers endpoint `/2/users/:id/followers` returns up to 1,000 accounts per page ([follows docs](https://docs.x.com/x-api/users/follows/introduction)). Page size does not change the price. 1,000 profiles or 1,000 followers cost $10.

We have three routes, and their prices are far apart. [`twitter/profile`](/en/twitter-api/profile) looks up one account per call, with follower, following, and post counts, for $0.000556. That is $0.556 per 1,000 accounts, 18 times less than X, and the smallest gap in this article. `twitter/profiles_by_ids` takes up to 20 numeric IDs per call. The catalog price is $0.000806 per call, not per account, and the catalog says it returns no bio and no follower counts.

We tried it at 00:31, 00:39, and 01:48. All three tries returned 503 `unavailable` with "Not charged" in the response. So we have no measured price per 1,000 for it. The table shows the catalog estimate of $0.0403 (20 accounts per call), and our conclusions do not use it. `twitter/search_users`, which finds accounts by keyword, also returned 503 at 00:31 and 01:48, with no charge.

First, a key point about followers: the two sides do not sell the same thing. On X, `/2/users/:id/followers` pages through all followers of an account. Our [`twitter/followers_list`](/en/twitter-api/followers_list) reads the visible followers, and the catalog says that it does not promise the full graph. So it returns a sample. To sample who follows an account, we charge $0.000556 for 2,000 accounts. For a complete list with no gaps, only X can do it, at $20 for 2,000 accounts.

At 00:23 Singapore time we asked for the followers of @XDevelopers with `limit` 2,000. One call returned 2,000 unique accounts. Each account had follower, following, and post counts, verified status, and creation date. Use this capability for questions such as the share of new zero-follower accounts. Do not use it for full graph analysis, or when you must reach every follower.

| Among 2,000 followers of @XDevelopers | Accounts | Share |
| --- | --- | --- |
| Zero followers | 292 | 14.6% |
| Zero posts | 399 | 20.0% |
| Zero followers and zero posts | 162 | 8.1% |
| Created in 2026 | 868 | 43.4% |
| Created in 2025 | 180 | 9.0% |
| Has a bio | 1,101 | 55.0% |
| Verified | 0 | 0.0% |

This small table shows why cheap follower data is useful. The share of zero-follower, zero-post accounts is a common signal of follower quality. At $0.010 per account on X, 2,000 followers cost $20. Few teams pay that for one competitor account.

## Test 4: replies and single posts

X has no separate replies endpoint. To get the replies under a post, you usually search with the `conversation_id:` operator, and each reply costs $0.005 as a post ([search operators](https://docs.x.com/x-api/posts/search/integrate/operators)). Our match is `twitter/comments`. It needs the post `id`, and `limit` goes up to 50. At 00:30 we read the replies to the @XDevelopers pricing post from October 30, 2024, which shows 1,332 replies.

With `limit` 50, we got 47 replies, all unique, from 42 authors. The first reply was from the same day as the post, and the last was from May 2025. At 00:31 we read a popular post from October 2026 that shows 605 replies, and got 50 replies from 49 authors. Each call cost $0.000556, so the 97 replies cost $0.0115 per 1,000. The same 97 replies cost $0.485 as posts on X.

Note the cap: `twitter/comments` returns at most 50 replies per call and has no page parameter. For a post with 1,332 replies, we return only about the first 50. If you need the full reply tree, page through X search with `conversation_id:`. X charges per post, so 1,332 replies cost about $6.66.

| Call | Time (SGT) | Post | Replies shown on the post | Replies returned | Authors | Charged | Same count on X |
| --- | --- | --- | --- | --- | --- | --- | --- |
| c01 | 00:30:45 | @XDevelopers pricing post, 2024-10-30 | 1,332 | 47 | 42 | $0.000556 | $0.235 |
| c02 | 00:31:30 | @cursor_ai post, 2026-10-12 | 605 | 50 | 49 | $0.000556 | $0.250 |

Lookup by post ID is a different case. X `/2/tweets` takes up to 100 IDs per call and charges $0.005 per returned post ([post lookup docs](https://docs.x.com/x-api/posts/lookup/introduction)). Our `twitter/post` takes one ID per call. At 00:31 we looked up the October 2024 pricing post. The call took 10.8 seconds, returned fields such as 3,996 likes, 1,332 replies, and 2,252,652 views, and cost $0.000556.

For 1,000 posts, X costs $5 and we cost $0.556, a gap of only 9 times. You may have a long list of post IDs, for example from a public research dataset. Then the X batch lookup of 100 IDs per call is faster to run. We still cost less, but you send 100 times more requests.

## Trends: per-request pricing on both sides

Trends are the cleanest comparison, because both sides charge per request. X Trends cost $0.010 per request ([pricing page](https://docs.x.com/x-api/getting-started/pricing)), and you select a place by WOEID. Our `twitter/trending` costs $0.000556 per request and takes a two-letter country code. The catalog lists 35 regions, such as us, uk, jp, sg, and br.

At 00:25 Singapore time, the US list returned 51 entries with rank and period (`period` was Live for all of them, and the `volume` field was empty in all 51). Per 1,000 requests, the cost is $10 against $0.556, or 18 times. Trends change fast, so a monitor often checks every hour, which is 24 calls a day. Over one year, that is $87.60 on X and $4.87 on our side.

| How often you read trends | Calls per year | X ($0.010 per call) | EveryInfra ($0.000556 per call) |
| --- | --- | --- | --- |
| Once a day | 365 | $3.65 | $0.203 |
| Once an hour | 8,760 | $87.60 | $4.87 |
| Every 15 minutes | 35,040 | $350.40 | $19.48 |

## Failures, empty results, and rate limits: are they charged?

Teams often skip this point when they pick an API, and it is where bills surprise them. Our rule is on the [pricing page](/en/pricing): failed calls and empty results are not charged. We made 4 calls on purpose that could not return data. Five more calls got 503 because a capability was not available at that time. All 9 calls cost $0.

| Case | Time (SGT) | HTTP | Response | Charged |
| --- | --- | --- | --- | --- |
| Rate limit: the key's 10 calls a minute were used up | 00:21:56 | 429 | `rate_limited`, "Nothing was charged", `retry_after` 4 s | $0 |
| Account that does not exist | 00:23:05 | 200 | Empty result, `billing.reason` is `empty_result_refunded`, `refund.status` is `succeeded` | $0 |
| X parameter name `query` copied as is | 00:23:34 | 422 | `missing_param`, tells you to use `keyword`, with a working example | $0 |
| No API key | 00:27:03 | 401 | `missing_key`, "Nothing was charged" | $0 |
| `twitter/profiles_by_ids`, three tries | 00:31:03, 00:39:04, 01:48:11 | 503 | `unavailable`, `retryable` is true, "Not charged" | $0 |
| `twitter/search_users`, two tries | 00:31:50, 01:48:19 | 503 | `unavailable`, "Not charged" | $0 |

Look at the response bodies. For an account that does not exist, we returned HTTP 200 with an empty result. The response had `billing.reason` set to `empty_result_refunded` and `refund.status` set to `succeeded`. We hold the charge first and return it at once when no data comes back.

When we copied the X parameter name `query`, we got HTTP 422 `missing_param`. Its `next_steps` said "Add the required `keyword` (`query` is not a parameter here)" and gave a working sample request. This helps an AI agent fix its own call. A rate-limited call returned HTTP 429 with "Nothing was charged" and a `retry_after` value in seconds.

X does not talk about refunds for failures, but its billing unit means most failures cost nothing. Reads are billed per object in the response, so a 404 or an empty result has no object and no charge ([pricing page](https://docs.x.com/x-api/getting-started/pricing)). Three other points need care. First, your balance can go slightly below zero, and then X blocks all requests until you pay the negative balance (the "Credit balance" section of the same page). Second, auto-recharge can run at most once every 5 minutes, so a burst of use can still show "out of credits" errors. Third, X returns HTTP 429 with the title "Usage Capped" when you reach the cap of 3 million posts per month.

It does the same at the spending limit that you set in the console. A paying customer posted response headers in a [forum thread from July 1](https://devcommunity.x.com/t/429-usage-capped-on-pay-per-use-across-multiple-read-endpoints-despite-healthy-rate-limits-and-console-limits/269581). The headers showed 1,499 of 1,500 requests left in the window, but the response was a usage-capped 429. Your retry code must treat a rate-limit 429 and a usage-cap 429 differently. A retry does not fix a usage cap.

## The 24-hour deduplication rule: X has it, we do not

The "Deduplication" section of the X pricing page says that all resources are deduplicated within one UTC day. If you request the same post many times in a day, X charges once, and the window resets at midnight UTC. The page also calls this a "soft guarantee" that can fail in edge cases such as outages ([pricing page](https://docs.x.com/x-api/getting-started/pricing), [usage and billing](https://docs.x.com/x-api/fundamentals/post-cap)). We do not have this rule. Each call costs the same, even if most items are ones you already have.

This rule makes one use case cheaper on X: frequent polling of a quiet query. We checked it with two searches for "x api pricing" at 00:17 and 00:29 Singapore time. The call at 00:29, 12 minutes later, returned 200 posts. Of these, 171 were in the first result and 29 were new to us. But only 3 of the 29 were posted between the two calls. The other 26 were older posts that moved into the top 200 when the ranking changed.

The third call at 00:38 had 174 posts in common with the first, 26 new ones, and again only 3 posted in between. On X, the 171 repeats on the same UTC day are free, so the second call costs $0.145 for 29 posts. If your program asks only for posts after the last call, the second call returns 3 posts for $0.015. Our second call costs $0.000556 again. So we cost less while each call has more than 0.11 posts that you did not read that day ($0.000556 ÷ $0.005). Below that, X costs less.

In general terms: if you poll every 15 minutes (96 calls a day), our cost is fixed at 96 × $0.000556 = $0.0534 a day. The X cost is the number of new unique posts that day times $0.005. The two costs meet at about 10.7 new posts a day. With hourly polling, the break-even point drops to about 2.7 posts a day.

| Pair | Gap | In both | New in the later call | Posted between the calls | X for this call (after same-day dedup) | EveryInfra for this call |
| --- | --- | --- | --- | --- | --- | --- |
| s01 → s01b | 12 min | 171 | 29 | 3 | $0.145 | $0.000556 |
| s01 → s01c | 21 min | 174 | 26 | 3 | $0.130 | $0.000556 |
| s01b → s01c | 8 min | 173 | 27 | — | — | $0.000556 |

![Log-log line chart of the daily cost of polling one query every 15 minutes, against the number of new posts per day. X API is a rising line at $0.005 per new post, with repeats free on the same day. EveryInfra every 15 minutes is a flat teal line at $0.0534 a day, and the two lines cross at about 10.7 new posts a day. EveryInfra every hour is a dashed flat line at $0.0133 a day, with a break-even point near 2.7 posts. Below the break-even point X costs less, and above it EveryInfra costs less.](https://everyinfra.com/articles/x-api-alternative/fig-05-dedup-breakeven-line.en.light.svg)

So the answer depends on volume. Take a rare keyword, a small account, or a topic with few new posts a day. There, X pay-per-use costs less and has no duplicate data. A popular topic is different, but first we must say whether our side can keep up. At 00:24 Singapore time we searched "openai" with `sort: latest`. All 100 returned posts fell inside 14 minutes and 22 seconds (16:09:54 to 16:24:16 UTC). From this one 14-minute window, we estimate roughly ten thousand new posts a day for this keyword. To get all of them on X costs about $50 a day, plus author charges after November 22.

On our side, a poll every 14 minutes costs about $0.056 a day. But only a test can show if those polls catch every new post. After the review of this article, we ran the same request three more times, at 02:45, 02:59, and 03:13 Singapore time (`keyword` openai, `sort: latest`, `limit` 200). Each call cost $0.000556, $0.001668 in total, and these calls are not part of the 27 above. The result was different from the call at 00:24. Each call returned 200 posts, but the oldest posts were from 2023. Only 25 to 35 posts in each call were from the 24 hours before the request, and only 0, 0, and 1 were from the 15 minutes before it. The posts were not in reverse time order: in about half of the adjacent pairs, the second post was newer. About 130 posts repeated between one call and the next.

So in these three calls, `sort: latest` acted more like top ranking. A poll every 14 minutes did not catch all new posts for a popular keyword. To collect a popular topic completely and in real time, use the X filtered stream or recent search, and pay per post. Our side is good for cheap samples of how a discussion moves, but it does not promise full coverage. If you only need to watch a few competitor accounts and can miss a post now and then, see [how we watch competitor posts with Claude Code](/en/blog/claude-code-channels-competitor-post-alerts).

## Monthly bill: from 1,000 to 100,000 posts a day

Now put the unit prices into a project shape: N new unique posts a day for 30 days. The X bill is N × 30 × $0.005, and after November 22 you multiply by about 2.86 if you need authors. Our bill is the calls per day × 30 × $0.000556. For unique posts per call we use the median of our search tests, 200 posts.

| Unique posts per day | Posts per month | X (posts only) | X (posts plus author, from Nov 22) | EveryInfra |
| --- | --- | --- | --- | --- |
| 1,000 | 30,000 | $150 | $429 | $0.0834 |
| 5,000 | 150,000 | $750 | $2,145 | $0.4170 |
| 10,000 | 300,000 | $1,500 | $4,290 | $0.8340 |
| 50,000 | 1,500,000 | $7,500 | $21,450 | $4.17 |
| 100,000 | 3,000,000 | $15,000 | $42,900 | $8.34 |

![Line chart with a log scale on the vertical axis: the 30-day bill at 1,000, 5,000, 10,000, 50,000, and 100,000 posts a day. X posts only goes from $150 to $15,000 a month. X posts plus author goes from $429 to $42,900. EveryInfra, at 200 unique posts per call, goes from $0.0834 to $8.34. At 100,000 posts a day, X reaches its cap of 3 million posts a month.](https://everyinfra.com/articles/x-api-alternative/fig-04-monthly-cost-line.en.light.svg)

Look at the right end of the chart. 100,000 posts a day is 3 million a month, which is exactly the pay-per-use cap on X. Above it, you need Enterprise. X also gives two different messages here. The [developer.x.com home page](https://developer.x.com/) says "No fixed monthly costs, no monthly caps". The [docs pricing page](https://docs.x.com/x-api/getting-started/pricing) and the [usage and billing page](https://docs.x.com/x-api/fundamentals/post-cap) both state a cap of 3 million post reads per month.

We follow the docs. If your plan comes near that number, confirm it in the console. On our side there is no monthly item cap. The limit is per minute: 60 calls per minute per account by default, shared by all keys on the account. At 200 posts per call, that is up to 12,000 posts a minute in theory. For more, you can buy a 30-day rate pack or reach a higher top-up tier ([pricing page](/en/pricing)).

![Screenshot of the developer.x.com home page. Below the large heading "A New Developer Experience", a teal box marks one line of small text: An all-new Developer Console with consumption-based billing. No fixed monthly costs, no monthly caps.](https://everyinfra.com/articles/x-api-alternative/img-shot-x-devhome.webp)

The developer.x.com home page says "no monthly caps", but the pricing page in the docs says 3 million posts a month. Screenshot taken Nov 9, 2026, 01:55 SGT. [developer.x.com home page screenshot](https://developer.x.com/)

## Credits, minimum spend, and free credits

| Item | X API pay-per-use | EveryInfra |
| --- | --- | --- |
| Billing unit | Reads per returned object, writes per request | Per call, one price per call |
| Monthly fee or minimum | No monthly fee, no minimum, buy credits first | No monthly fee, top-up tiers start at $10 |
| Free credits | $20 after the first card and first purchase, plus up to $50 matched on the first auto-recharge, both expire after 3 months | $1 after you star two GitHub repositories, valid for 24 hours |
| Credit expiry | Not stated for purchased credits, 3 months for free credits | Topped-up balance does not expire |
| Rewards | 10%, 15%, or 20% back as xAI API credits at $200, $500, or $1,000 spend per billing cycle | None |
| Monthly cap | 3 million post reads | No item cap, 60 calls per minute by default |
| Spending limit | You can set a limit per billing cycle in the console | Calls stop when the balance is used |
| Failures and empty results | No returned object, no charge | Not charged, the held amount comes back at once |

X changed its free credit rule once already. At launch on October 2, adding a first card earned $20. [From October 13](https://docs.x.com/x-api/getting-started/free-credits), you get the $20 only after your first credit purchase. Prepaid cards do not qualify, and each physical card can earn the credit once across all accounts. So before you read your first post on X, you must save a credit or debit card and buy credits. The xAI rewards work only on the xAI API, and you must first link your xAI team to your X developer account in the console.

## How many steps from sign-up to your first public post

The X [Getting Access](https://docs.x.com/x-api/getting-started/getting-access) page lists three steps: create a developer account, create an app, and save your credentials. Each step has smaller steps inside it. You sign in to console.x.com with an X account, accept the Developer Agreement and Policy, and describe your use case. You create an app with a name, description, and use case. The console then shows your API key, bearer token, and other credentials, and the docs warn that they appear only once. Then you buy credits so that calls can run.

To post or read DMs as a user, you also set up OAuth 2.0. You change the app permissions to read and write, and you add a callback URL. The README of xurl, the official X command-line tool, adds one more case. OAuth can work while reads still return `client-not-enrolled`. In that case, the app must go to the Pay-per-use package and the Production environment in the console ([xurl repository](https://github.com/xdevplatform/xurl)).

![Animated flow chart with a 10-second loop. The top row shows 8 X API steps: sign in with X, accept the agreement, describe the use case, create an app, save the keys that appear only once, add a card, buy credits, and call with a bearer token. The bottom row shows 3 EveryInfra steps: sign up and get a key, use trial credit or top up, and make a curl or MCP call. A teal box moves through the steps on both rows at the same time and stops on the last step of the short row.](https://everyinfra.com/articles/x-api-alternative/fig-02-setup-flow.en.light.svg)

Our side has three steps. Sign up in the [quickstart](/en/docs#quickstart) and get a key. Use the $1 trial credit or top up. Call with curl, an SDK, or MCP. You do not need an X account, and you can try before you add a card. The X steps are not wasted effort. X asks for an account, an agreement, and a use case because its API can post and read DMs for users. Those powers need review. A read-only public-data project does not use those powers, so for that project the steps feel heavy.

## Connecting AI agents: MCP on both sides

On [June 30](https://devcommunity.x.com/t/announcing-the-hosted-x-mcp/269558), X launched a hosted X MCP server at `https://api.x.com/mcp` (protocol version 2025-06-18). It can search the full archive, look up users, manage bookmarks, read trends and news, and draft Articles ([MCP docs](https://docs.x.com/tools/mcp)). There are two ways to connect. For read-only use, put the app bearer token in the MCP client header.

To act as your own account, run the open-source `xurl mcp` bridge. On the first run, it opens a browser for OAuth 2.0 login. The docs say that X OAuth needs your own developer app and does not support dynamic client registration. So you cannot connect it with only a URL, as you can with many remote MCP servers.

The docs describe X MCP tools as calls to X API endpoints and do not list a separate MCP price. Our estimate is that the endpoint prices apply, so each post read through MCP still costs $0.005. This is our inference, and the console shows the real charge. X also has an open-source server that you can host yourself, [xmcp](https://github.com/xdevplatform/xmcp). It turns the X API OpenAPI description into tools and leaves out streaming and webhook endpoints.

```text
{
  "mcpServers": {
    "xapi": {
      "url": "https://api.x.com/mcp",
      "headers": { "Authorization": "Bearer $X_BEARER_TOKEN" }
    },
    "everyinfra": {
      "url": "https://api.everyinfra.com/mcp",
      "headers": { "Authorization": "Bearer ${EVERYINFRA_API_KEY}" }
    }
  }
}
```

This sample config connects both servers. The X part copies the app-only example in the X docs. Our remote MCP address is `https://api.everyinfra.com/mcp`. Our tool names start with `everyinfra_`, and the model reads the catalog before it calls a capability ([MCP setup page](/en/mcp-server)).

With both servers connected, a sensible split is this. The model uses the X tools to post or to read your bookmarks and DMs. It uses our tools to read public posts, followers, and trends at volume. The MCP protocol itself is defined at [modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2025-06-18).

## Fields: the two sides do not return the same data

The fields on the two sides do not map one to one, so do not plan a drop-in swap. By default, the X post object returns only `id`, `text`, and `edit_history_tweet_ids`. You request every other field by name with `tweet.fields`, `user.fields`, and expansions ([data dictionary](https://docs.x.com/x-api/fundamentals/data-dictionary)). Our side returns one fixed set of fields.

You do not name them, and you cannot pick them. The table lists only fields that read-only projects use often. The X column follows the X docs, and our column follows the catalog `response_fields` and the real output of our 9 searches.

| What you need | X API | EveryInfra `twitter/search` |
| --- | --- | --- |
| Text, post time, link | Yes (`text`, `created_at`, by name) | Yes (`text`, `posted_at`, `url`) |
| Likes, reposts, replies, quotes | Yes (`public_metrics`) | Yes (`like_count` and three more) |
| Views | Yes (`public_metrics.impression_count`) | Yes (`view_count`, present on 99.7% of posts) |
| Bookmarks | Yes | Yes (`bookmark_count`) |
| Author follower count, verified | Needs the `author_id` expansion, $0.010 per user from Nov 22 | In each post (`author_follower_count`, `author_is_verified`) |
| Images and video | Needs `attachments.media_keys`, $0.005 each from Nov 22 | `media` field with video URL and length |
| Edit history | Yes | No |
| Context annotations (topics, entities) | Yes (`context_annotations`) | No |
| Non-public metrics for your own posts | Yes, with user auth | No |
| Place | Yes (`geo.place_id` expansion) | No |

The last rows are fields that X has and we do not: edit history, context annotations, private metrics for your own posts, and places. If your analysis needs them, for example counts by X topic class, stay on the official API.

## Moving from the X API: what to change in your code

You may already have code for X API v2 and want to move the public read-only part to EveryInfra. The changes are in a few places. We list what we found in our live calls, and the X column follows the X docs. We hit the most common problem ourselves.

When you send the X `query` parameter as is, you get 422 `missing_param`. The `next_steps` field in the response tells you to use `keyword` and gives a working sample request. An AI agent can read this, fix the call, and try again, and the failed call costs nothing.

| What to change | X API v2 | EveryInfra | How |
| --- | --- | --- | --- |
| Search parameter | `query` | `keyword` | Rename it. Search syntax (`from:`, `lang:`, `since:`) stays the same |
| Items per call and paging | Up to 100 per page, next page with `next_token` ([pagination docs](https://docs.x.com/x-api/posts/search/integrate/paginate)) | `limit` up to 200, no page parameter | For more, split by `since:` and `until:` and send more calls |
| Date range | Request parameters such as `start_time` and `end_time` ([timeline docs](https://docs.x.com/x-api/posts/timelines/introduction)) | Put it in `keyword`, for example `since:2026-11-01` | Move the dates into the search expression |
| Engagement counts | Nested fields in `public_metrics`, requested with `tweet.fields` ([data dictionary](https://docs.x.com/x-api/fundamentals/data-dictionary)) | Top-level `like_count`, `retweet_count`, `view_count`, and more | Change the field paths |
| Post time | `created_at` | `posted_at` | Rename the field |
| Post and user IDs | Strings | Strings. The catalog says to keep them as strings, so JavaScript does not lose digits | No change |
| Cost tracking | Console and the [Usage API](https://docs.x.com/x-api/usage/introduction) | `billing.charged_usd` in each response | You can log cost per call |
| HTTP 429 | Rate limit, or the monthly cap (Usage Capped) | Rate limit only, with `retry_after` and "Nothing was charged" | Handle the two kinds of 429 apart |

After the change, pull the same keyword once on each side. Compare the item count, the date range, and the fields that you really use. Then move live traffic. Check two points with care. First, ranking: we return top posts by default, and `sort: latest` does not promise time order. In 3 of our 4 calls with `sort: latest`, most posts were old (see the end of the deduplication section). Second, fields: in 2 of our 9 searches, posts came back without author follower counts. If your code depends on such fields, handle empty values.

## When the official X API is the better choice

We state this part plainly. In the cases below, the official X API is the better choice, and sometimes the only choice.

First, any write action. Posts, replies, deletes, DMs, lists, and bookmarks go only through the official API, at $0.005 to $0.20 per request. We read public data only and cannot post for you. Note that after February 23, 2026, X allows programmatic replies only when the original author summons your account with a mention or a quote. From April 20, self-serve tiers also lost follows, likes, and quote posts through the API ([changelog](https://docs.x.com/changelog)).

Second, real-time streams. The X Filtered Stream pushes new posts that match your rules with a P99 latency of about 4 to 5 seconds. A pay-per-use account gets 1,000 rules and 1 connection ([filtered stream docs](https://docs.x.com/x-api/posts/filtered-stream/introduction)). Our model is request and response, so polling is the fastest option, and we cannot push posts within seconds.

Third, counts without content. The X Counts endpoints return post volume for a query by minute, hour, or day. Recent counts cost $0.005 per request, and full-archive counts cost $0.010 ([counts docs](https://docs.x.com/x-api/posts/counts/introduction)). To learn how many times a word appeared each day last year, X needs a few requests. We have no match for this. You would need to download posts and count them, and the result would not be complete.

Fourth, your own account data. Owned Reads cost $0.001 per object for your own posts, mentions, bookmarks, followers, and following, and you also get private metrics such as impressions. For a dashboard of your own account, the official API is cheap and complete.

Fifth, low-volume polling. As shown above, X deduplication is cheaper for one query polled every 15 minutes with fewer than about 10.7 new posts a day.

Sixth, terms and compliance. Data from the X API comes with the [Developer Agreement](https://docs.x.com/developer-terms/agreement) (last updated April 27, 2026) and the [Developer Policy](https://docs.x.com/developer-terms/policy), so the rights and duties are clear. If your compliance team requires data from the platform's own channel, the answer is the official X API. The agreement has specific limits. For example, you cannot use X content to train or fine-tune a foundation model. You must also delete content within 24 hours after a removal request. Read each clause before you sign.

## X terms and legal limits

The X [Terms of Service](https://x.com/en/tos) apply to people who use X, and the Developer Agreement sets extra limits on data from the API. In the EU, researchers can also ask for platform data under Article 40 of the Digital Services Act ([regulation text](https://eur-lex.europa.eu/eli/reg/2022/2065/oj)). The European Commission also adopted a [delegated act on data access](https://digital-strategy.ec.europa.eu/en/library/delegated-act-data-access-under-digital-services-act-dsa). The X [automation rules](https://help.x.com/en/rules-and-policies/x-automation) add rules for automated posts and actions. Ask your lawyer what these terms mean for your project.

This article does not give legal advice. We can describe the limits of our method. This article reads only public posts, accounts, and lists. It does not log in, read DMs, or read protected accounts.

## Recent changes (October to November 2026)

| Date | Change | What it means for read-only projects | Source |
| --- | --- | --- | --- |
| 2026-10-13 | The $20 free credit now needs a first purchase | Adding a card is not enough, so you pay before you try | [free credits page](https://docs.x.com/x-api/getting-started/free-credits) |
| 2026-10-23 | Expansion objects will be billed from Nov 22 | In our sample, posts with author data cost about 2.86 times more; 3 times if every post has a different author, and more with media | [forum announcement](https://devcommunity.x.com/t/inform-x-api-ppu-expansions-update/279110) |
| 2026-11-05 | New Livestream API routes, old routes removed on Jan 1, 2027 | Projects on the old live routes must move before the end of the year | [changelog](https://docs.x.com/changelog) |
| 2026-11-22 | Expansion objects start to cost the standard rate | Check which requests use `expansions` before that date | [forum announcement](https://devcommunity.x.com/t/inform-x-api-ppu-expansions-update/279110) |

Earlier this year: pay-per-use launched on February 6, and active legacy Free users got a one-time $10 voucher. On April 20, Owned Reads dropped to $0.001 and posts with links rose to $0.20. On May 4, search moved to a new index, and keyword search stopped returning reposts. Basic (May 21) and Pro (August 14) were scheduled to move to pay-per-use. The hosted X MCP launched on June 30. The [X changelog](https://docs.x.com/changelog) and the forum announcements show about one change a month, so plan for price changes in a long project. X is not the only official API that changes per-item prices often. Our [TikTok API pricing guide](/en/blog/tiktok-api-pricing) records the billing rules of the official TikTok API, if you want to compare.

## Get started: one live call first

Step 1: sign up in the [quickstart](/en/docs#quickstart) and get a key. After you star the everyinfra/everyinfra-agent-plugins and everyinfra/seo-skills repositories on GitHub, you can claim $1 of trial credit in the console. It is valid for 24 hours. Step 2: run the curl above with the keyword that matters to you, and check the `results` count and `billing.charged_usd`. Step 3: try other capabilities in the [marketplace](/en/market), or connect [MCP](/en/mcp-server) in your AI client.

All X capabilities are on the [Twitter/X data API page](/en/twitter-api), and prices are on the [pricing page](/en/pricing). If you also monitor another community platform, see the [Reddit data API](/en/reddit-api).

## FAQ

**Is the X API free?**

There is no free tier for new developers. Pay-per-use launched on February 6, 2026. After that, only apps that X classes as Public Utility Apps kept free access. Active legacy Free users got a one-time $10 voucher ([launch announcement](https://devcommunity.x.com/t/announcing-the-launch-of-x-api-pay-per-use-pricing/256476)).

New accounts get $20 after their first credit purchase, and that credit expires after 3 months. A user in r/Twitter asked the same thing in [this thread](https://www.reddit.com/r/Twitter/comments/1r2xosn/xtwitter_api_free_tier/), because a posting tool cannot pay per post.

**How much does X API pay-per-use cost, and is there a calculator?**

One post read costs $0.005, and one user read costs $0.010. One new post costs $0.015, one post with a link costs $0.20, and one trends request costs $0.010 ([pricing page](https://docs.x.com/x-api/getting-started/pricing)). X has no public calculator, but the console shows live spend. You can use the formula in this article: monthly cost = unique posts per day × 30 × $0.005. From November 22, add unique authors × $0.010 if you expand authors.

**What is a good x api alternative, according to Reddit?**

On Reddit, people name three options: stay on official pay-per-use, use a third-party data API, or write your own scraper. In an [r/Web_Development thread](https://www.reddit.com/r/Web_Development/comments/1qz8ae3/i_tried_the_new_x_api_its_nice_but_doesnt_look_so/), the author used the official API to sync bookmarks. The cost was about $1 per 200 posts, which felt expensive over time. Under the [r/Twitter free tier thread](https://www.reddit.com/r/Twitter/comments/1r2xosn/xtwitter_api_free_tier/), one reply suggested reverse engineering and many accounts, which risks bans and breaks the X terms. Use the official API to post. For public read-only data at volume, use the cost table in this article, and read its last column: for some rows the two sides do not sell the same thing.

**What happens when I reach the 3 million post cap?**

The [pricing page](https://docs.x.com/x-api/getting-started/pricing) says that pay-per-use allows up to 3 million post reads per monthly billing cycle, and more needs the Enterprise form. At the cap, requests return HTTP 429 "Usage Capped" until the next billing cycle, so retries do not help. We have no monthly item cap and allow 60 calls per minute by default. Some developers got this 429 before the cap. In [this forum thread](https://devcommunity.x.com/t/429-usage-capped-on-pay-per-use-across-multiple-read-endpoints-despite-healthy-rate-limits-and-console-limits/269581), two paying developers on June 30 and July 1 had healthy credit, spend caps, and rate limits, but still got usage-capped errors from time to time. The X team replied on July 2 that the issue was fixed. If this happens to you, check the console first, then search the forum for similar reports.

**Why does a post with a link cost $0.20?**

In its [April 16 pricing announcement](https://devcommunity.x.com/t/x-api-pricing-update-owned-reads-now-0-001-other-changes-effective-april-20-2026/263025), X said that from April 20, a post with a URL through the API costs $0.20. Summoned replies stay at $0.01, and a normal post rose from $0.01 to $0.015. The title of an [r/technology thread](https://www.reddit.com/r/technology/comments/1srwd4i/x_makes_it_1900_more_expensive_to_post_links_it/) calls it a 1,900% increase. We cannot help here, because we do not offer posting.

## References

1. X API pay-per-usage pricing and credits, X Developer Platform, read Nov 9, 2026, https://docs.x.com/x-api/getting-started/pricing
1. Free credit incentives for X API pay-per-use accounts, X Developer Platform, updated Oct 13, 2026, https://docs.x.com/x-api/getting-started/free-credits
1. Usage and Billing, X Developer Platform, https://docs.x.com/x-api/fundamentals/post-cap
1. Rate limits, X Developer Platform, https://docs.x.com/x-api/fundamentals/rate-limits
1. Getting Access, X Developer Platform, https://docs.x.com/x-api/getting-started/getting-access
1. About the X API, X Developer Platform, https://docs.x.com/x-api/getting-started/about-x-api
1. Search Posts, X Developer Platform, https://docs.x.com/x-api/posts/search/introduction
1. Timelines, X Developer Platform, https://docs.x.com/x-api/posts/timelines/introduction
1. User Lookup, X Developer Platform, https://docs.x.com/x-api/users/lookup/introduction
1. Follows, X Developer Platform, https://docs.x.com/x-api/users/follows/introduction
1. Post Lookup, X Developer Platform, https://docs.x.com/x-api/posts/lookup/introduction
1. Expansions, X Developer Platform, https://docs.x.com/x-api/fundamentals/expansions
1. Post Counts, X Developer Platform, https://docs.x.com/x-api/posts/counts/introduction
1. Filtered Stream, X Developer Platform, https://docs.x.com/x-api/posts/filtered-stream/introduction
1. Response Codes & Errors, X Developer Platform, https://docs.x.com/x-api/fundamentals/response-codes-and-errors
1. MCP servers for the X API and X developer docs, X Developer Platform, https://docs.x.com/tools/mcp
1. X API changelog, X Developer Platform, entry of Nov 5, 2026, https://docs.x.com/changelog
1. Developer Agreement, X, last updated Apr 27, 2026, https://docs.x.com/developer-terms/agreement
1. Developer Policy, X, https://docs.x.com/developer-terms/policy
1. Search operators, X Developer Platform, https://docs.x.com/x-api/posts/search/integrate/operators
1. Data dictionary, X Developer Platform, https://docs.x.com/x-api/fundamentals/data-dictionary
1. Usage API, X Developer Platform, https://docs.x.com/x-api/usage/introduction
1. X Activity API, X Developer Platform, https://docs.x.com/x-api/activity/introduction
1. XDK overview, X Developer Platform, https://docs.x.com/xdks/overview
1. Enterprise API interest form, X Developer Platform, https://docs.x.com/forms/enterprise-api-interest
1. X Developer Platform home page, X, read Nov 9, 2026, https://developer.x.com/
1. xurl, xdevplatform on GitHub, https://github.com/xdevplatform/xurl
1. xmcp, xdevplatform on GitHub, https://github.com/xdevplatform/xmcp
1. X API Playground, xdevplatform on GitHub, https://github.com/xdevplatform/playground
1. [Inform] X API PPU - Expansions Update, X Developers forum, Oct 23, 2026, https://devcommunity.x.com/t/inform-x-api-ppu-expansions-update/279110
1. Legacy X API Pro Plans Are Moving to Pay-Per-Use, X Developers forum, Aug 14, 2026, https://devcommunity.x.com/t/important-update-legacy-x-api-pro-plans-are-moving-to-pay-per-use-ppu/273255
1. Legacy X API Basic Plans Are Moving to Pay-Per-Use, X Developers forum, May 21, 2026, https://devcommunity.x.com/t/important-update-legacy-x-api-basic-plans-are-moving-to-pay-per-use-ppu/266305
1. Announcing the Launch of X API Pay-Per-Use Pricing, X Developers forum, Feb 6, 2026, https://devcommunity.x.com/t/announcing-the-launch-of-x-api-pay-per-use-pricing/256476
1. X API Pricing Update: Owned Reads Now $0.001, X Developers forum, Apr 16, 2026, https://devcommunity.x.com/t/x-api-pricing-update-owned-reads-now-0-001-other-changes-effective-april-20-2026/263025
1. Announcing the hosted X MCP, X Developers forum, Jun 30, 2026, https://devcommunity.x.com/t/announcing-the-hosted-x-mcp/269558
1. 429 usage-capped on pay-per-use thread, X Developers forum, Jul 1, 2026, https://devcommunity.x.com/t/429-usage-capped-on-pay-per-use-across-multiple-read-endpoints-despite-healthy-rate-limits-and-console-limits/269581
1. I tried the new X API - it's nice, but doesn't look so cheap long term, Reddit r/Web_Development, https://www.reddit.com/r/Web_Development/comments/1qz8ae3/i_tried_the_new_x_api_its_nice_but_doesnt_look_so/
1. X/Twitter api free tier?, Reddit r/Twitter, https://www.reddit.com/r/Twitter/comments/1r2xosn/xtwitter_api_free_tier/
1. X makes it 1,900% more expensive to post links, Reddit r/technology, https://www.reddit.com/r/technology/comments/1srwd4i/x_makes_it_1900_more_expensive_to_post_links_it/
1. X Terms of Service, X, https://x.com/en/tos
1. Automation rules, X Help Center, https://help.x.com/en/rules-and-policies/x-automation
1. Model Context Protocol Specification 2025-06-18, modelcontextprotocol.io, https://modelcontextprotocol.io/specification/2025-06-18
1. Regulation (EU) 2022/2065 (Digital Services Act), EUR-Lex, https://eur-lex.europa.eu/eli/reg/2022/2065/oj
1. Delegated act on data access under the DSA, European Commission, https://digital-strategy.ec.europa.eu/en/library/delegated-act-data-access-under-digital-services-act-dsa
1. EveryInfra data capability catalog, EveryInfra, read Nov 9, 2026, 00:14 SGT, https://api.everyinfra.com/api/v1/social/catalog