X API search: the two endpoints and what reads cost

#Quick answer

X API search is two endpoints. GET /2/tweets/search/recent returns Posts from the last 7 days and every developer can call it. GET /2/tweets/search/all returns Posts back to March 2006 and any pay-per-use or Enterprise account can call it, which is the part most guides get wrong. Both bill as Posts: Read at $0.005 per Post returned. Recent search tops out at 100 Posts per request, full-archive at 500.

Last updated: October 2026

The syntax is the easy part. What costs people days is that X rebuilt the search backend in May 2026 and changed two behaviours in the process, while the access tiers every third-party tutorial describes stopped existing in February. Search the web for this endpoint today and the first non-X result will still tell you to apply for the Academic Research track.

#The two endpoints side by side

Everything in this table comes from X's own search documentation and rate-limit reference, checked 17 October 2026.

That last row has a consequence people hit late. Because full-archive accepts app-only auth and nothing else, you cannot request non_public_metrics, organic_metrics or promoted_metrics from it. Impression counts on your own historical Posts have to come from a user-context endpoint instead. If you are still picking a token type, X API OAuth has the full scope-to-endpoint mapping.

By default the response is thinner than most people expect: id, text and edit_history_tweet_ids, and nothing else until you ask. Author, timestamp and metrics all arrive through tweet.fields and expansions.

curl "https://api.x.com/2/tweets/search/recent?query=python%20lang%3Aen&tweet.fields=created_at,public_metrics&expansions=author_id" \
  -H "Authorization: Bearer $BEARER_TOKEN"

#What a search run actually costs

Search reads are not priced as an endpoint. They are priced as resources, at $0.005 per Post returned, and that single number drives every design decision in a listening tool.

A full page of recent search is 100 Posts, so $0.50 per request. A full page of full-archive search is 500 Posts, so $2.50 per request. Run full-archive at its documented ceiling of 300 requests per 15 minutes and you are spending roughly $750 a quarter-hour. Pay-per-use accounts are capped at 3 million Post reads per monthly billing cycle, which is $15,000 of reads before X asks you to move to Enterprise.

The practical consequence: max_results is a billing control, not a performance knob. A broad query with max_results=500 and an unbounded pagination loop is how a prototype quietly eats a month of credits overnight. Our X API pricing breakdown covers the rest of the rate card, including the free credit incentives X added on 2 October 2026.

#Count first, then search

Counts are the cheapest thing on the X API and almost nobody uses them.

GET /2/tweets/counts/recent and GET /2/tweets/counts/all return the volume of Posts matching a query over time without returning any Posts. They take the same operators and the same query-length limits as their search twins, they group by minute, hour or day, and they are billed per request: $0.005 for recent, $0.010 for full-archive.

So sizing a query costs the same as reading one Post.

curl "https://api.x.com/2/tweets/counts/recent?query=%22x%20api%22&granularity=day" \
  -H "Authorization: Bearer $BEARER_TOKEN"

The response carries a total_tweet_count in meta. Multiply it by $0.005 and you know what the real search will cost before you run it. A query that matches 400,000 Posts in the last week is a $2,000 pull, and it is far better to learn that from a half-cent request than from an invoice. Full-archive counts paginate at 31 days per response at every granularity, so a multi-year trendline is a loop, but a cheap one.

#Retweets quietly left keyword search

On 4 May 2026, X retired the legacy search index behind the API and moved the endpoints onto the index that powers search in the app. The announcement lists faster responses and far fewer 503s, which developers wanted. It also lists this, which almost nobody noticed:

Retweets will no longer be returned in keyword-based searches (including when using the is:retweet operator).

Streaming was explicitly excluded. The Filtered Stream still returns retweets exactly as before. That means the same rule, expressed the same way, now produces different corpora depending on whether you stream it or search it, and any historical comparison that straddles May 2026 has a step change in it that has nothing to do with the topic you are tracking.

X's current operator reference still documents is:retweet, retweets_of: and retweets_of_tweet_id: without any note about the change. Both things are published by X and they do not agree. Treat your own test query as the source of truth here, and if retweet volume matters to your product, build on the stream or on the X Activity API rather than on search.

#The min_likes saga, and the operator that 400s

On 19 January 2026, X deprecated min_likes, min_replies and min_reposts on both search endpoints, with a note that replacements were being evaluated. Filtered-stream operators such as followers_count were unaffected.

Three and a half months later, the same three operators came back as a headline feature of the new index. They are in the current documentation, they take a non-negative integer, and they work on recent and full-archive alike:

"x api" min_likes:50 -is:reply lang:en

What still does not work is the spelling people reach for first. min_faves: and min_retweets: are X web search syntax, the kind you would type into X advanced search in a browser. The API rejects both with a 400. X added an explicit warning about it to the operator reference, which tells you how often it happens.

A few other operator rules are worth knowing before you write a parser:

• Conjunction-required operators cannot stand alone. has:media, is:reply, lang:en and the rest of that group need at least one standalone operator in the query. A bare lang:en is an error, not an empty result.
• -is:nullcast only works negated. It excludes promoted-only Posts and there is no positive form.
• entity: is recent-search only. context: works on both, but takes a numeric domain/entity pair rather than a string.
• has:video_link means native X video. has:media is the broader match across photo, GIF and video.

#Pagination, edits, and the thing that breaks nightly jobs

Pagination is a next_token in the meta object that you echo back on the following request until it stops appearing. The official Python and JavaScript XDKs wrap this in an iterator, so for page in client.posts.search_recent(...) handles it for you. That convenience is also how unbounded loops happen, so cap the iteration yourself.

Posts can be edited up to 5 times within 30 minutes of publishing, and search always returns the latest version. edit_history_tweet_ids carries every ID, oldest first. For a nightly job this never matters. For a near-real-time pipeline it does: a Post you captured 90 seconds after publication may not be the Post that exists an hour later, and the only way to detect that is to compare the array.

That 7-day boundary on recent search is the other quiet failure. It is a rolling window, not a calendar one, so a job that runs weekly and misses a day loses that day permanently unless you pay for full-archive to backfill it. Daily collection into your own store is cheaper than re-reading history at $0.005 a Post.

#Is the API the right tool here?

For monitoring, research and anything you need to defend with a reproducible method, yes. The pay-per-use move made the archive reachable for a side project in a way the old $5,000 tiers never did, and the data arrives structured.

For growth work, the arithmetic rarely clears. Reading a thousand Posts a day to find reply opportunities is $5 a day in credits before you have written a line of product, and the write endpoints are priced separately on top. That gap is why so much of this market runs on browsers instead, and it is worth reading the trade-offs in our X API alternatives breakdown before committing a build to either route. Browser automation is a gray area under X's automation rules in a way the API is not, and that is a real difference, not a marketing one.

Whichever way you go, start with a counts call. It is the half-cent that tells you whether the rest of the plan is affordable.