Twitter (X) API Endpoints: the X API v2 Map, What Each Read Costs, and the TwitterAPI.io Path for the Same Job

The X API v2 charges per resource returned. The rate card we fetched from docs.x.com/x-api/getting-started/pricing lists five read prices (posts $0.005, users $0.010, following and followers $0.010, likes $0.001, profile update $0.005), two write prices (post create $0.015, $0.200 with a URL), a cap of 3 million post reads per monthly billing cycle on pay-per-usage with an Enterprise plan above it, and the sign-up incentive of $20 in credits when you save a first eligible card plus a match of the first auto-recharge up to $50. Families not on that list (lists, spaces, trends, DMs, communities) are not priced on that page, so check the console before relying on them.

TwitterAPI.io also charges per item returned, in credits at $1 = 100,000 credits: tweet endpoints are 15 credits per tweet with a 15-credit minimum per request (so an empty search is $0.00015 and a full 20-tweet page is $0.003, no per-request cap), profiles are 18 credits per user ($0.18 per 1,000), and followers or followings pages are 1 to 3 credits per user returned depending on the page tier. Reads need an X-API-Key header and no X account. Rate limits are 0.2 requests a second before the first payment, 20 once paid, 50 on Scale, 500 on Business, up to 1,000 on request. New accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days); purchased credits never expire.

Authentication differs more than pricing does. Every X API v2 call needs an app in the developer portal and either an app-only bearer token or a user-context token (OAuth 1.0a or OAuth 2.0 with PKCE); the reverse-chronological home timeline, bookmarks, DMs and every write require user context. On TwitterAPI.io every read is the API key alone; only the write family needs a session, created once with /twitter/user_login_v2 and reused as login_cookies.

Response shapes also differ in a way the tables below make explicit. X v2 returns data (an array or object) plus includes and meta with next_token. TwitterAPI.io returns a top-level list whose key depends on the endpoint (tweets, users, followers, followings, trends, or data.tweets for last_tweets and data for user/info) plus has_next_page and next_cursor. Page cursors are covered in our pagination guide; here we only note which endpoints returned a cursor in the probe.

These are the endpoints most integrations live on. The X docs index at docs.x.com/x-api/llms.txt confirms the four doc paths; posts/lookup/introduction states that GET /2/tweets returns up to 100 Posts in one request, and posts/timelines/introduction states that the user Post timeline reaches up to 3,200 most recent Posts and the mention timeline up to 800. Every row is priced at $0.005 per post read on X. On TwitterAPI.io each row is a tweet endpoint at 15 credits per tweet, and the probe confirmed 20 tweets per page on all three accounts for last_tweets, mentions and advanced_search, and exactly the 5 requested ids back from /twitter/tweets.

Three details from the probe matter when you switch. last_tweets nests its list under data.tweets, unlike every other tweet endpoint, and it excludes replies unless you pass includeReplies=true. advanced_search is one endpoint for both of X's search windows; from:NASA with queryType=Latest returned the same 20-tweet page shape as the timeline call, and the page shape does not change when you add since: or until:. And tweets by id is the only tweet endpoint in the probe that returned no has_next_page key, which makes sense because you supplied the list.

X v2 exposes engagement as separate endpoints under the post id, documented at posts/quote-tweets/introduction, posts/get-reposted-by, posts/get-liking-users and posts/likes/quickstart/likes-lookup; replies have no endpoint of their own and are fetched by searching conversation_id:. On TwitterAPI.io quotes, replies, retweeters and the whole thread are each one call that takes tweetId. For the probe we picked the most-replied tweet on each account's latest page and called all four.

thread_context is the odd one out: it returned 27, 34 and 37 tweets for the three accounts rather than a fixed 20, because it returns the thread as X renders it (root, the author's own continuation posts and the replies X ranks first); it carried has_next_page: true and a cursor for @NASA and @nytimes and false for @github's shorter 27-tweet thread. Its tweet objects had 26 fields against 30 on the other tweet endpoints; the 26 are the common core listed in the fields section below, so nothing you would normally read is missing. The slowest call of the whole probe was a replies page for @NASA at 11,551 ms, against a median of 3,165 ms for that endpoint, which is why the code at the end of this page sets a 30-second timeout rather than 10.

The X docs at users/follows/introduction list GET /2/users/:id/followers and GET /2/users/:id/following for reads and POST /2/users/:id/following plus DELETE /2/users/:source_user_id/following/:target_user_id for managing follows; user lookup lives at users/lookup/introduction and user search at users/search/introduction. On X, users are $0.010 per user read and followers or following are $0.010 per user returned. On TwitterAPI.io a profile is 18 credits and a followers page is 1 to 3 credits per user.

The probe surfaced the one trap in this family: there are two user-object dialects. user/info, batch_info_by_ids and tweet/retweeters return camelCase objects (userName, followers, following, statusesCount, isBlueVerified, canDm, isAutomated), 25 fields on the lookup endpoints and 17 on retweeters. followers, followings, user/search and verifiedFollowers return snake_case objects (screen_name, followers_count, following_count, statuses_count, profile_image_url_https), 17 to 21 fields; the followers pages also carry a userName alias next to screen_name, and user/search adds username and isBlueVerified. Write one normalizer and route by endpoint.

Two other probe facts: the followings response uses the key followings, not followers, which is easy to miss if you copy the followers loop; and @NASA's followings page came back with 115 users and has_next_page: false (the account follows fewer than a page's worth), so a page is "up to 200", not always 200. /twitter/user/verifiedFollowers (takes user_id, returned 20 per page) and /twitter/user/followers_ids (ids only, no profile metadata) have no direct v2 counterpart but are cheaper ways to answer "who follows this account" at scale.

The remaining read families are smaller and, on X, are not individually priced on the rate card we fetched. The list, space and trends paths on TwitterAPI.io come from the published OpenAPI spec; we probed trends (30 items for WOEID 1, each wrapped as {"trend": {...}} with a metadata block giving refresh_interval_millis) and left lists and communities to their own pages because they need an id you must already hold.

The following X endpoints have no TwitterAPI.io read equivalent in the published spec. We list them because a map that hides gaps is not a map.

X v2 writes are documented at posts/manage-tweets/introduction (POST /2/tweets, DELETE /2/tweets/:id), posts/likes/quickstart/manage-likes, posts/retweets/quickstart/manage-retweets, users/follows/introduction (POST /2/users/:id/following), lists/manage-lists/introduction and media/introduction; all need user-context auth, and the rate card prices a created post at $0.015, or $0.200 if it carries a URL.

TwitterAPI.io has a write family too, and it works differently: you log an X account in once with /twitter/user_login_v2 ($0.10, with a proxy you supply) and receive login_cookies; each subsequent action is $0.002 per call. The call acts as that account, so X can rate-limit, lock or suspend it; keep a human pace; the session can need a re-login; and each HTTP 200 call is billed whether or not X accepted the action.

The spec also carries a _v3 generation (/twitter/user_login_v3, /twitter/send_tweet_v3, /twitter/like_tweet_v3, /twitter/retweet_v3) that keys actions by user_name after a login instead of passing cookies on every call. Either way, reads never touch any of this: no X account is needed to run every table above this section.

Documentation tells you the maximum page size. The probe tells you what came back on a given day for three real accounts: one page of 15 TwitterAPI.io read endpoints for @NASA, @nytimes and @github, 37 requests in total, every one of them HTTP 200 with no API-level error (status: "error" never appeared), 1,654 items, and an upper-bound cost of 10,398 credits, about $0.10. The table lists the median items per page, the response key you read, whether a cursor came back, how many fields each item carried, and the wall time of the client call (which includes the study client's rate-limit spacing of up to 0.2 s and ran while other probes shared the same client).

Tweet objects are consistent across endpoints. All seven tweet-returning endpoints carried the same 26 core fields on every item: id, url, twitterUrl, text, createdAt, lang, type, source, author, likeCount, retweetCount, replyCount, quoteCount, viewCount, bookmarkCount, conversationId, isReply, inReplyToId, inReplyToUserId, inReplyToUsername, entities, extendedEntities, card, place, quoted_tweet and retweeted_tweet. Timeline, search, mentions, replies and quotes add four more (isPinned, isQuote, isRetweet, isConversationControlled, 30 in total); tweets by id adds article, article_summary and isLimitedReply on top of those (33). So a parser written against advanced_search reads every other tweet endpoint unchanged.

Wall time. The median call took 2,151 ms and the 90th percentile 3,398 ms; trends was fastest at 1,132 ms and the single slowest call was a replies page at 11,551 ms. These are client wall times for a page of 20 to 200 items from a shared, rate-limited study client, not a latency benchmark; budget a 30-second timeout and retry once on a 5xx.

Because both APIs bill per resource, the cost of a page is the item count times the unit price. The table applies each rate card to the median page the probe returned. X prices come from docs.x.com/x-api/getting-started/pricing: $0.005 per post read and $0.010 per user, follower or following read. TwitterAPI.io prices are 15 credits per tweet (15-credit minimum per request), 18 credits per profile, and 1 to 3 credits per follower or following returned, at $1 = 100,000 credits. Trends, user search and verified followers are left out because they are not on the summary rate card used here; see twitterapi.io/pricing for those.

Per 1,000 tweets the two cards sit at $0.15 and $5.00, about 33x apart, on every tweet endpoint; the gap is wider on followers because X prices each follower at the full user rate while TwitterAPI.io tiers the page. The minimum matters at the other end: an empty TwitterAPI.io search still costs 15 credits ($0.00015), so a poll that finds nothing every 60 seconds for a month is 43,200 checks, $6.48, and every 5 minutes $1.30. The whole 37-request probe, with followers pages counted at the 3-credit tier, came to at most 10,398 credits, about $0.10; the same 1,654 items would be $0.005 or $0.010 each on X. Subscription plans (Starter $29, Builder $99, Pro $199, Scale $499, Business $1,499 a month) add bonus credits on top of the per-item prices; the pricing page has the current numbers.

Question: for each TwitterAPI.io read endpoint that stands in for an X API v2 family, what does one page really return (status, item count, top-level keys, per-item fields, wall time) and what does that page cost under the published rate card, so the endpoint map can show measured values instead of documented maximums.

Accounts: three public organization accounts, @NASA, @nytimes and @github, chosen because each has a deep timeline, mentions, followers in the hundreds of thousands or more, and at least one recent post with replies, quotes and reposts.

Method: for each account, one page of /twitter/user/info, /twitter/user/last_tweets, /twitter/user/mentions, /twitter/user/followers, /twitter/user/followings, /twitter/tweet/advanced_search (from:<account>, queryType=Latest), /twitter/tweets with the first 5 ids from the timeline page, and /twitter/tweet/replies, /twitter/tweet/quotes, /twitter/tweet/retweeters and /twitter/tweet/thread_context for the most-replied tweet on that page; plus one call each of /twitter/user/batch_info_by_ids (the 3 ids), /twitter/user/verifiedFollowers, /twitter/user/search (nasa) and /twitter/trends (WOEID 1). 37 requests through a rate-limited, read-only client, collected in 2026. For every call we logged the HTTP status, the client wall time, the item count, the list key, has_next_page, whether next_cursor was present, and the set of field names on the items; the analysis script turns those into per-endpoint medians, field unions and intersections, and rate-card credits.

What the sample cannot show: one page per endpoint per account is a coverage check, not a benchmark. Wall times include the client's own request spacing and were measured while other studies shared the same client, so they are upper bounds on server time. Page sizes for quotes and followings vary with how much exists (@github's tweet had 10 quotes; @NASA's page of followings had 115 users), so "20" and "200" are typical, not guaranteed. Lists, communities and spaces were not probed because they need an id the study did not hold, and no write endpoint was exercised. Costs are the rate card applied to the item counts, not a bill; followers pages are shown as the 1-to-3-credit range because the per-page tier was not measured.

Aggregates and field-name inventories only. The three accounts are organizations; the followers, followings, retweeters, replies, user-search and verified-followers pages list private individuals and were read only to count items and field names, then discarded. The gzip-compressed raw pages of the organization accounts' own profiles, timelines, mentions, search results, quotes and threads are kept with the study together with the analysis and chart scripts.