What changed from the old Twitter API to the current X API is practical: it affects how you scope the work, what you pay for, and what kind of workflow you can trust once the data starts coming back.
The economics changed first, and that changed the work. I had to stop treating the API like a familiar search box and start treating it like an operating decision: what is the question, what is worth paying to pull, and what can I trust once the data is in hand?
The economic change
As of April 29, 2026, the official X docs position the API as pay-per-use, credit-based access rather than a simple flat subscription model. The parts that matter most for research work are straightforward:
- credits are purchased up front in the Developer Console
- different endpoints have different costs
- usage is tracked in real time
- pay-per-use plans currently carry a monthly cap of 2 million Post reads
- Enterprise is the path if you need higher or custom volume
The documentation I checked for this section:
That changes the operator mindset immediately. On the old Twitter API, the main question was often “can I get access?” On the current X API, the question is “what exactly am I asking for, and what is the cheapest honest way to get it?”
The procedural change
The modern X API makes one workflow much more important than it used to be:
- count the space
- refine the query
- pull only what you actually need
X now exposes a cleaner counts layer and a cleaner search layer than the older “just pull a bunch of tweets and see what happens” habit encouraged.
X documents the split this way:
- recent search: last 7 days, available to all developers
- full-archive search: back to 2006, available to pay-per-use and Enterprise customers
- recent counts: last 7 days without returning posts
- full-archive counts: full history without returning posts
Two details especially matter for research work:
- full-archive search can return up to 500 posts per request
- full-archive counts paginates at 31 days per response
References for that split:
That counts-first step saves money up front. You can see whether a query is worth pulling before you pay for the posts themselves.
I do not have an internal memo from X saying this is the reason, but the pricing shape also reads like a defensive language-model posture. If you make large-scale historical text expensive to count, page through, and pull in volume, you raise the cost of treating the platform like cheap raw material for model training.
The structural change
The newer API is also cleaner from a data-shape perspective.
The old v1.1 search world was workable, but it came with a narrower recent-search posture, older auth patterns, and a payload shape that people learned mostly because they had to.
The current X API v2 stack gives you more deliberate control:
- fields and expansions
- annotations
- conversation-level structure
- multiple auth methods
- official SDKs
X’s migration docs state that v2 is the direction of travel and that it is meant to replace older standard and enterprise search patterns over time.
The migration and access docs I used:
How I think about connection now
For read-only public-data work, the simplest mental model is:
- create the app
- get the Bearer Token
- use counts to size the topic
- use search to retrieve the posts
For public read work, the docs still point to Bearer Token access as the clean starting point.
Simple recent-search example
curl "https://api.x.com/2/tweets/search/recent?query=python%20lang%3Aen%20-is%3Aretweet" \
-H "Authorization: Bearer $BEARER_TOKEN"
Simple counts-first example
curl "https://api.x.com/2/tweets/counts/all?query=%22He%20Gets%20Us%22%20lang%3Aen%20-is%3Aretweet&granularity=day" \
-H "Authorization: Bearer $BEARER_TOKEN"
Official Python SDK example
from xdk import Client
client = Client(bearer_token="YOUR_BEARER_TOKEN")
for page in client.posts.search_recent(query="X API lang:en -is:retweet", max_results=10):
if page.data:
print(page.data[0].text)
break
The auth and SDK references:
The query design shift
The query operator system is where a lot of people either save money or waste it.
The operator reference gives you enough structure to think in layers before you ever make a paid pull:
- exact phrase matching
- language restriction
- retweet exclusion
- user-specific operators like
from: - URL matching like
url: - media and content filters
The operator reference that governs that layer:
For research work, this is the right default posture:
- start narrow
- require campaign or entity anchors
- separate direct discourse from link-driven amplification
- use counts before archive search
That last point sounds small, but it is the difference between a research workflow and an expensive curiosity workflow.
The real difference
The old Twitter API rewarded exploration.
The current X API rewards disciplined acquisition.
I do not think that makes the API worse. It means more design work before the first paid pull.
Once I accepted that, the He Gets Us dataset got more useful. I stopped trying to pull something interesting and started pulling evidence I could explain and check later in the stored record.