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

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 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, 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.

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 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.

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. You buy credits first, and each call deducts credits by endpoint. On May 21, 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, 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, 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.

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 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). 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). Until November 21, these extra objects do not count toward usage.

The X Developer Platform team posted an announcement on October 23. 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.

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). 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.

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, rate limits).

Both endpoints cost $0.005 per returned post. Our match is twitter/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.

# 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.

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.

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). 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. 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.

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). The /2/users/by lookup takes up to 100 usernames per call (user lookup docs). The followers endpoint /2/users/:id/followers returns up to 1,000 accounts per page (follows docs). 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 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 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.

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). 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.

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). 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), 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.

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: 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.

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). 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. 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, usage and billing). 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.

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.

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.

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 says "No fixed monthly costs, no monthly caps". The docs pricing page and the usage and billing page 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).

Credits, minimum spend, and free credits

X changed its free credit rule once already. At launch on October 2, adding a first card earned $20. From October 13, 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 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).

Our side has three steps. Sign up in the 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, 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). 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. It turns the X API OpenAPI description into tools and leaves out streaming and webhook endpoints.

{
  "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).

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.

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). 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.

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.

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).

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). 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). 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 (last updated April 27, 2026) and the Developer 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 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). The European Commission also adopted a delegated act on data access. The X automation rules 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)

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 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 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 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, or connect MCP in your AI client.

All X capabilities are on the Twitter/X data API page, and prices are on the pricing page. If you also monitor another community platform, see the Reddit data 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).

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, 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). 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, 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, 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 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, 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, 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 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
2. 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
3. Usage and Billing, X Developer Platform, https://docs.x.com/x-api/fundamentals/post-cap
4. Rate limits, X Developer Platform, https://docs.x.com/x-api/fundamentals/rate-limits
5. Getting Access, X Developer Platform, https://docs.x.com/x-api/getting-started/getting-access
6. About the X API, X Developer Platform, https://docs.x.com/x-api/getting-started/about-x-api
7. Search Posts, X Developer Platform, https://docs.x.com/x-api/posts/search/introduction
8. Timelines, X Developer Platform, https://docs.x.com/x-api/posts/timelines/introduction
9. User Lookup, X Developer Platform, https://docs.x.com/x-api/users/lookup/introduction
10. Follows, X Developer Platform, https://docs.x.com/x-api/users/follows/introduction
11. Post Lookup, X Developer Platform, https://docs.x.com/x-api/posts/lookup/introduction
12. Expansions, X Developer Platform, https://docs.x.com/x-api/fundamentals/expansions
13. Post Counts, X Developer Platform, https://docs.x.com/x-api/posts/counts/introduction
14. Filtered Stream, X Developer Platform, https://docs.x.com/x-api/posts/filtered-stream/introduction
15. Response Codes & Errors, X Developer Platform, https://docs.x.com/x-api/fundamentals/response-codes-and-errors
16. MCP servers for the X API and X developer docs, X Developer Platform, https://docs.x.com/tools/mcp
17. X API changelog, X Developer Platform, entry of Nov 5, 2026, https://docs.x.com/changelog
18. Developer Agreement, X, last updated Apr 27, 2026, https://docs.x.com/developer-terms/agreement
19. Developer Policy, X, https://docs.x.com/developer-terms/policy
20. Search operators, X Developer Platform, https://docs.x.com/x-api/posts/search/integrate/operators
21. Data dictionary, X Developer Platform, https://docs.x.com/x-api/fundamentals/data-dictionary
22. Usage API, X Developer Platform, https://docs.x.com/x-api/usage/introduction
23. X Activity API, X Developer Platform, https://docs.x.com/x-api/activity/introduction
24. XDK overview, X Developer Platform, https://docs.x.com/xdks/overview
25. Enterprise API interest form, X Developer Platform, https://docs.x.com/forms/enterprise-api-interest
26. X Developer Platform home page, X, read Nov 9, 2026, https://developer.x.com/
27. xurl, xdevplatform on GitHub, https://github.com/xdevplatform/xurl
28. xmcp, xdevplatform on GitHub, https://github.com/xdevplatform/xmcp
29. X API Playground, xdevplatform on GitHub, https://github.com/xdevplatform/playground
30. [Inform] X API PPU - Expansions Update, X Developers forum, Oct 23, 2026, https://devcommunity.x.com/t/inform-x-api-ppu-expansions-update/279110
31. 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
32. 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
33. 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
34. 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
35. Announcing the hosted X MCP, X Developers forum, Jun 30, 2026, https://devcommunity.x.com/t/announcing-the-hosted-x-mcp/269558
36. 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
37. 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/
38. X/Twitter api free tier?, Reddit r/Twitter, https://www.reddit.com/r/Twitter/comments/1r2xosn/xtwitter_api_free_tier/
39. 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/
40. X Terms of Service, X, https://x.com/en/tos
41. Automation rules, X Help Center, https://help.x.com/en/rules-and-policies/x-automation
42. Model Context Protocol Specification 2025-06-18, modelcontextprotocol.io, https://modelcontextprotocol.io/specification/2025-06-18
43. Regulation (EU) 2022/2065 (Digital Services Act), EUR-Lex, https://eur-lex.europa.eu/eli/reg/2022/2065/oj
44. 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
45. EveryInfra data capability catalog, EveryInfra, read Nov 9, 2026, 00:14 SGT, https://api.everyinfra.com/api/v1/social/catalog