TIMELINE
Twitter Timeline API: Pull Any Account at $0.04/1K
What is the Twitter (X) Timeline API?
The Twitter timeline API is a REST endpoint that returns any public account's tweets as paginated JSON at $0.0008 per call, about $0.04 per 1,000 tweets on a full 20-tweet page, under one flat usage ceiling of 600 requests a minute and 20 concurrent per key. TwitterAPIs provides four timeline endpoints: originals only, tweets with replies, home timeline, and a complete auto-paginated full-history pull, all on one Bearer key with no X developer account required.
Quick answer
To pull a user's timeline, call GET /twitter/user/tweets?userName=elonmusk with your Bearer key. Each response returns about 20 tweets plus a next_cursor and has_more. Pass the cursor back on the next call and repeat until has_more is false. For the full account history in one shot, use /twitter/user/tweets/complete. That one is the premium path at $0.0024 a call; the paged timeline reads cost $0.0008. No X developer account, and one flat ceiling of 600 requests a minute and 20 concurrent per key rather than a per-endpoint quota. 99 total endpoints on the same key.
Four timeline endpoints, one Bearer key
TwitterAPIs maps every timeline use case to a dedicated endpoint, all billed at the same flat $0.0008 per call. Pull originals only, include replies, read your own home feed, or fetch the complete history of any account in a single request.
| What you pull | Endpoint | Per page | Docs |
|---|---|---|---|
| Original tweets only | GET /twitter/user/tweets | ~20 per page | View docs |
| Tweets and replies (full activity) | GET /twitter/user/tweets_and_replies | ~20 per page | View docs |
| Home timeline (authenticated) | GET /twitter/user/home_timeline | ~20 per page | View docs |
| Full history (auto-paginated) | GET /twitter/user/tweets/complete | All pages, auto-paginated | View docs |
Every endpoint runs on the same Bearer key, and the paged timeline reads are $0.0008 a call, so cost scales with how much you pull, not which timeline shape you request. The one exception is user/tweets/complete at $0.0024, which pages the full history for you in a single request.
Pull a timeline with cursor pagination
The tweets endpoint lives at GET /twitter/user/tweets. Pass the userName you want and read the tweets array. To walk the full timeline, omit cursor on the first call, then pass the returned next_cursor back on each subsequent call and loop until has_more is false. Each call is $0.0008 and returns about 20 tweets.
Get the first page of tweets
curl -H "Authorization: Bearer YOUR_API_KEY" \
"https://api.twitterapis.com/twitter/user/tweets?userName=elonmusk"The response is structured JSON with a next_cursor and has_more on every page. No HTML to parse, no proxy to rotate. Read the user tweets endpoint docs.
Pull the full account history in one request
The /twitter/user/tweets/complete endpoint auto-paginates through every available tweet and returns them merged into a single response. You skip the cursor loop entirely. It is the fastest path to archiving a full account history or building a training dataset from an account's entire output.
Fetch the complete tweet history
curl -H "Authorization: Bearer YOUR_API_KEY" \
"https://api.twitterapis.com/twitter/user/tweets/complete?userName=elonmusk"Use the complete endpoint when you need the entire history in one call and the account has a manageable tweet count. For accounts with very large histories, walk pages manually with user/tweets to control memory and resumability. Read the complete endpoint docs.
Pull tweets with replies: full account activity
Switch to GET /twitter/user/tweets_and_replies when you need the full chronological activity stream including replies. The response shape is identical to user/tweets, so the same cursor loop works without changes.
curl -H "Authorization: Bearer YOUR_API_KEY" \
"https://api.twitterapis.com/twitter/user/tweets_and_replies?userName=elonmusk"Each call returns about 20 items at $0.0008. Use this endpoint when you need to map how an account engages in conversations, not just what it publishes. Read the tweets and replies docs.
Endpoint breakdown: what each timeline path returns
| Endpoint | Payload | Page size | Best for |
|---|---|---|---|
| user/tweets | Original posts only, no replies | ~20 per page | Brand monitoring, content audits, post-level analytics |
| user/tweets_and_replies | Posts + replies in chronological order | ~20 per page | Full account activity, sentiment analysis, engagement mapping |
| user/home_timeline | Authenticated user's own feed (requires user context) | ~20 per page | Reading the home feed of your own account |
| user/tweets/complete | Entire tweet history, all pages merged into one response | Auto-paginated | Full account history exports, training data, archival pipelines |
The three paged endpoints bill at $0.0008 per call. The complete endpoint is $0.0024, and is also the only one without a cursor response, since it handles pagination internally.
TwitterAPIs timeline vs the official X API and scraping
| Option | Price | Auth | Limits | Full history |
|---|---|---|---|---|
| TwitterAPIs | $0.0008 a call, ~20 tweets, so $0.04 / 1,000 | Bearer token, 30s signup | 600 req/min per key | Full history via cursor or auto-paginated complete endpoint |
| Official X API timeline | Gated, enterprise pricing | X developer account, OAuth app approval | Hard tweet caps per 15-minute window on every tier | Limited lookback on lower tiers; full history on enterprise only |
| Browser scraping the profile tab | $0 plus proxy and compute cost | Session cookies or tokens | IP bans within hours of a high-volume run | Breaks on any X layout change, partial pulls only |
Pricing: flat and pay-as-you-go
$0.04
per 1,000 tweets pulled
$0.50
free credits at signup, no card
$0
subscription, you pay per call only
A paged timeline call is $0.0008 and returns about 20 tweets, so 1,000 tweets costs roughly $0.04, and user/tweets/complete is $0.0024. See the full cost breakdown on the Twitter API pricing page or check the pricing page for the full endpoint list.
How far back a timeline goes, and what to do when it stops
The question that decides whether a timeline endpoint fits your job is not what it returns but how deep it goes. Paging a timeline walks backwards through an account's posts, and on a prolific account you will eventually reach a point where the cursor stops yielding new items. That is the platform's reach into its own timeline surface rather than a failure of the request, and a third-party API reading that same surface inherits the same limit.
Three ways to work with that rather than against it. If you need an account's deepest available history in one operation, user/tweets/complete exists for exactly this and bills at the premium rate because it does the walk for you. If you need coverage beyond what any timeline surface reaches, search with a from: operator and a date window is a different index and frequently reaches material a timeline walk will not. And if the requirement is genuinely a complete historical corpus with a contractual guarantee behind it, that is an enterprise data agreement with the platform rather than a REST endpoint from anybody.
The practical design implication is to start collecting before you need the history. A daily job that stores an account's new posts costs a handful of calls and builds an archive nobody can take away, whereas trying to reconstruct two years retroactively is bounded by what the platform still surfaces today. This is the single most common regret we hear from teams six months into a project.
One detail that catches people mid-backfill: an empty page is the stop condition, not an error. Follower-graph endpoints keep returning a non-null cursor past the end, while list and affiliate endpoints null it out, so a loop written against has_more behaves correctly on every paged endpoint and a loop written against a null cursor does not.
Every field on a timeline tweet
A timeline call does not return ids you then have to expand. Each item is a full tweet object with the author's profile attached, which is why a timeline pull is one billed call rather than one call plus a lookup per row. The table is the published schema, so you can shape your database before writing the client.
| Field | Type | What it is good for |
|---|---|---|
id | string | Primary key. A string because X ids exceed the safe integer range in JavaScript |
text | string | Full post text with URLs expanded, not the truncated card version |
created_at | string | Post timestamp, the field every time-series chart is built on |
author | object | The full user object of the poster, so a timeline pull needs no second profile call |
url | string | Canonical x.com status URL, for linking straight back to the source |
lang | string | BCP-47 language code X detected, the cheapest first filter on a mixed corpus |
favorite_count | integer | Likes at fetch time |
retweet_count | integer | Reposts at fetch time |
reply_count | integer | Replies at fetch time |
quote_count | integer | Quote posts at fetch time |
bookmark_count | integer | Bookmarks, an under-used signal because it tracks saved-for-later intent |
view_count | integer | Impressions. Null on posts made before X started reporting the metric |
is_retweet | boolean | Filter these out before counting anything, or one viral repost skews the set |
is_quote | boolean | Marks a quote post, which is commentary rather than an original |
is_reply | boolean | Separates conversation from broadcast, the main axis of timeline analysis |
retweeted_tweet | object | The original post, present only when is_retweet is true |
quoted_tweet | object | The quoted post nested one level, present only when is_quote is true |
conversation_id | string | Root id of the thread, which is how you reassemble a conversation |
in_reply_to_status_id | string | The post being replied to, null when this is not a reply |
in_reply_to_username | string | Handle being replied to, useful for mapping who talks to whom |
entities | object | Parsed hashtags, mentions, URLs and cashtags, always present and empty when unused |
media | array | Attached media at the top level, so you do not have to dig into extended entities |
display_text_range | array | The UTF-16 span of display text inside text, for trimming leading mentions |
is_limited_reply | boolean | True when X restricts who can reply, which changes how a low reply count reads |
source | string | Posting client label. Frequently null, so never build a required field on it |
Four of these decide whether your numbers are right. is_retweet is the one people forget: a timeline that includes reposts double-counts a single popular post across every account that amplified it, and the fix is a filter rather than a different endpoint. view_count is null on older posts because X did not report impressions before it launched the metric, so an average that treats null as zero will drift downward the further back you look. is_limited_reply changes how a low reply count reads, since restricted replies are not the same as an ignored post. And conversation_id is what turns a flat list of replies back into a thread.
Engagement counts are a reading, not a fact
Every count on a tweet object is the value at fetch time, and it keeps moving after you stored it. That is obvious when stated and it is the single most common source of wrong numbers in timeline work, because a table of tweets pulled once and joined against later is silently comparing measurements taken at different ages.
The practical rules are short. Store a fetch timestamp beside every row, so an engagement figure always carries the age of its own measurement. Compare posts at the same age rather than on the same day: a post from this morning and one from last month are not comparable readings, and a leaderboard built on raw counts is mostly a leaderboard of which post is oldest. If you need a growth curve, re-fetch the same ids on a schedule rather than re-running the whole timeline, since a detail call on 50 known ids is cheaper and more precise than another full crawl.
A deleted post is the other case worth handling once rather than repeatedly. Once it is gone from X it is gone from every source that reads X, so the copy in your database is the only copy. Treat that as a reason to store what you collect rather than to plan on re-fetching it.
If you need more than timeline tweets
The timeline endpoints cover what an account posts. To find tweets across all accounts by keyword or hashtag, use the Twitter search API. To track every tweet that mentions an account in near real time, use the Twitter mentions API. To pull follower and following lists for the same account, use the Twitter followers API. To resolve the profile that owns a timeline by handle or numeric id, use the Twitter user API. To enumerate the members of any public X list by list ID, use the Twitter list API. To wire timeline calls into an AI agent, install the MCP server or read the full API docs. You get 99 endpoints across the X data surface on the same key.
Twitter timeline API FAQ
The Twitter timeline API is a set of REST endpoints that return a user's tweets as paginated JSON. TwitterAPIs exposes 99 endpoints across the X data surface, including four timeline-specific paths: user/tweets (originals only), user/tweets_and_replies (full activity), user/home_timeline (authenticated feed), and user/tweets/complete (auto-paginated full history). The three paged timeline reads cost $0.0008 a call, so pulling 1,000 tweets costs $0.04 flat, and user/tweets/complete is the premium path at $0.0024 a call because it walks the whole history for you. No subscription and no X developer account required.
user/tweets returns only the account's original posts, filtering out replies. user/tweets_and_replies returns the full chronological activity stream including both posts and replies. Use user/tweets when you want clean tweet-only data for brand monitoring or content analysis. Use user/tweets_and_replies when you need the complete picture of how an account engages, such as for sentiment analysis, conversation mapping, or full account audits.
No. TwitterAPIs uses a single Bearer token you copy from your dashboard after signup. There is no OAuth app review, no X developer account, and no waiting period. The only exception is user/home_timeline, which reads the authenticated user's own feed and therefore requires a user context token. For pulling any other public account's timeline, the standard Bearer key is all you need.
Yes. Use GET /twitter/user/tweets to get only the account's original posts. Replies, quote-tweets-as-replies, and thread continuations are stripped from the response. Each page returns about 20 original tweets at $0.0008 per call. If you need replies included, switch to user/tweets_and_replies on the same key.
Call GET /twitter/user/tweets/complete with the userName of the account. The endpoint auto-paginates through the entire history and returns all tweets merged into a single response, so you do not have to write cursor-loop logic yourself. For very large accounts with tens of thousands of tweets, use the standard user/tweets endpoint with manual cursor pagination instead: omit cursor on the first call, read the next_cursor from the response, pass it back on the next call, and repeat until has_more is false. Each page returns about 20 tweets and costs $0.0008.
The three paged timeline reads are $0.0008 a call (source: twitterapis pricing); user/tweets/complete is the premium path at $0.0024 because it walks the whole history for you. The paged endpoints return about 20 tweets per page, so pulling 1,000 tweets costs roughly $0.04. There is no monthly subscription and no minimum spend. You start with $0.50 in free credits after a 30-second signup with no card required, enough to pull around 600 tweets before you spend a cent. The official X API gates timeline access behind paid developer tiers with per-window tweet caps, making TwitterAPIs the cheapest pay-as-you-go path to high-volume timeline exports.
On your first request, omit the cursor parameter. The response includes a next_cursor string and a has_more boolean. Pass next_cursor back in the cursor parameter on your next call to fetch the following page. Repeat the loop until has_more is false. The same cursor pattern applies to user/tweets, user/tweets_and_replies, and user/home_timeline. user/tweets/complete handles the pagination internally and returns all pages merged, so no cursor loop is needed for that endpoint.
Yes. TwitterAPIs publishes an MCP server at @twitterapis/mcp that exposes all timeline endpoints as native tools. Any MCP-compatible AI agent or IDE can call user/tweets, user/tweets_and_replies, or user/tweets/complete directly, without writing HTTP request logic. See the MCP page for installation and usage instructions.
Pull any Twitter timeline without an X developer account
$0.04 per 1,000 tweets. $0.50 free credits at signup. Cursor pagination, full history, 600 req/min per key.
Next read
Continue exploring related pages: