May 19, 20269 min read

Twitter/X Data for Developers: What’s Actually Available

Twitter data used to be the easy case. For roughly a decade the official API was generous, well documented, and free enough that social research and side projects were built on it as a matter of course.

That changed. The free tier now covers posting and very little reading, and the paid tiers start at a price that rules out most side projects and a good number of real products. Whatever you think of that decision commercially, the practical consequence for developers is that “just use the official API” stopped being the default answer.

So the question became: what can you actually get, and what is it good for?

The endpoints, grouped by what they’re for

The Twitter/X Data API wraps a third-party provider behind ApiMask-owned response schemas — which is the detail that matters most for anyone building on it. If the upstream provider changes its shape, the normalisation layer absorbs it and your integration keeps working. That is the same argument as using a maintained Instagram API instead of a scraper: you are buying insulation from someone else’s changes.

Everything is a GET with query parameters, on https://twitter-x-api.p.rapidapi.com.

Reading accounts and posts

  • /v1/twitter/profile — a profile by username.
  • /v1/twitter/user-tweets — recent tweets for a username, with include_replies to control whether the reply stream is included.
  • /v1/twitter/tweet — a single tweet by ID.
curl --request GET \
  --url "https://twitter-x-api.p.rapidapi.com/v1/twitter/profile?username=OpenAI" \
  --header "X-RapidAPI-Key: $RAPIDAPI_KEY" \
  --header "X-RapidAPI-Host: twitter-x-api.p.rapidapi.com"

include_replies=false is the flag people forget. An account that replies a lot will fill your timeline fetch with conversational fragments that make no sense without their parent, and if you are computing engagement averages they will skew the numbers badly downward.

Search and monitoring

  • /v1/twitter/search — keyword, hashtag, or advanced query, with a type of latest or otherwise.
  • /v1/twitter/brand/mentions — a brand plus a comma-separated keywords list, which is the social-listening shape rather than raw search.
GET /v1/twitter/brand/mentions?brand=OpenAI&keywords=ChatGPT,API&type=latest&limit=20

The distinction is worth understanding. Raw search gives you everything matching a string, including the noise. The brand endpoint is built around the actual monitoring question — mentions of this brand, in these contexts — which is usually what you wanted.

Conversations and threads

  • /v1/twitter/replies — replies to a tweet, with sort=relevance or chronological.
  • /v1/twitter/thread — this is the useful one.
GET /v1/twitter/thread?tweet_id=2075367885438890134&format=markdown&limit=20

Reconstructing a thread by hand is genuinely fiddly: you follow reply chains, filter to the original author, handle branches where other people replied mid-thread, and reassemble in order. This endpoint does that and will hand you the result as markdown, which means a “read this thread as an article” feature is a single call rather than a subsystem.

The insight endpoints

/v1/twitter/search/insights, /v1/twitter/profile/insights, and /v1/twitter/tweet/conversation-insights layer analysis over the raw data — engagement, sentiment, topics, and for conversations, questions, objections, and controversy signals.

The documentation is specific that these use deterministic analysis rather than a generative model. That is a meaningful property: the same input produces the same output, every time. If you are putting a sentiment score in a customer dashboard, reproducibility is worth more than nuance — a number that changes when nothing changed is a number your users stop trusting.

Four things worth knowing before you build

Engagement counts are snapshots. Likes and reposts on a tweet from an hour ago will be different in an hour. If you are ranking or reporting on them, store the timestamp with the value and say what it is. Overwriting a single column throws away the trend, which is usually the thing users actually want to see.

Search is not a complete archive. No third-party access, and no affordable official tier, gives you the full historical firehose. Search results skew recent. If your product implies “all mentions ever”, it will disappoint. If it promises “recent mentions”, it will deliver.

Deleted content disappears. Tweets get deleted, accounts get suspended or go private. Your cached copy is not a licence to keep serving it, and continuing to display content the author removed is the fastest route to a complaint. Design for records that stop resolving.

Rate limits are a design input, not an error case. Fetching timelines for five hundred tracked accounts on every dashboard load will not work. Fetch on a schedule into your own store, and serve the dashboard from that. Handle RATE_LIMIT_EXCEEDED (429) with backoff — see Rate limits and Errors.

What people actually build with this

Brand and competitor monitoring. brand/mentions on a schedule, plus conversation-insights on anything that spikes. The value is not the mention count; it is catching the complaint thread before it is a problem.

Creator and lead research. profile plus profile/insights across a candidate list, to rank by genuine engagement rather than follower count. Follower counts are the least informative number available and the one most often used.

Content repurposing. thread with format=markdown to turn a thread into a blog draft or a newsletter section.

Dataset construction. Timelines and search results as a corpus for classification or trend work.

The obligations that come with it

The same line as with any social data: an API solves the access problem, not the compliance one.

Tweets are public, but they are also personal data under GDPR and comparable regimes — you need a lawful basis to store them, a retention policy, and a process for deletion requests. X’s terms constrain redistribution regardless of how you obtained the data. And there is a real difference between aggregate analysis of a topic and building individual profiles of named people; the second attracts scrutiny the first does not.

Take advice for your jurisdiction and your use case. This paragraph is not it.

The Instagram API Collection covers the other major social surface — see pulling Instagram data without scrapers for how the two compare, and why the maintenance argument is the one that actually decides this.