CHANGELOG
Changelog
What is the TwitterAPIs changelog?
TwitterAPIs is a pay-per-call Twitter/X data API, and this changelog is its dated release log: every new endpoint, pricing change, and platform update since the February 2026 public launch. As of its latest entry, September 13, 2026, TwitterAPIs has shipped 109 endpoints (65 reads, 44 writes) across 44 dated releases, each naming the exact route, what changed, and the per-call price.
We have shipped 109 endpoints since that release, 65 reads and 44 writes, per our own surface-parity gate, which checks all 10 published surfaces against the live router on every deploy, so the counts on this page are the ones production serves rather than a number kept up to date by hand.
How we price these releases
Written by Emma, twitterapis developer relations
Standard reads are a flat $0.0008 per call, about 20 tweets each, and the June 2026 price consolidation below left them untouched. Premium endpoints run $0.0016 to $0.004. There is no subscription and no monthly minimum, so an endpoint's price is the whole cost of calling it.
Endpoint rates last checked August 2, 2026.
September 13, 2026
Set your own avatar and header image, the two profile writes that were missing
POST /twitter/user/update_avatar replaces the profile picture on the account behind your registered session, and POST /twitter/user/update_banner replaces the wide header image. Each takes one field of base64-encoded image bytes, image and banner respectively, sent in the JSON request body: not a URL, not multipart, and not a media_id from media/upload. Each returns ok and costs $0.0016. Together with update_profile, every editable part of your own profile is now reachable.
- -Send the image base64-encoded in the JSON request body. There is no URL-fetch form, no multipart upload, and no media_id: these do not take a media_id from media/upload, and you do not need to call it first.
- -There is NO UNDO and X keeps no history of a previous image. If you might want the old one back, read profile_image_url or cover_picture from user/info and save the file BEFORE you call this. That is not boilerplate caution: a real account lost its header image during this work because nobody had captured the original URL.
- -To see your new banner, read cover_picture from user/info. Use that field: a banner reads as empty on some other X surfaces even when the account has one, so an empty answer elsewhere does not mean the write missed.
- -An image X cannot decode comes back as an error, not as a success that quietly changed nothing.
- -109 endpoints total now, 65 reads and 44 writes.
September 13, 2026
Edit your own profile, one endpoint and a genuinely partial update
POST /twitter/user/update_profile changes the display name, bio, location or link on the account behind your registered session. It is a PARTIAL update: send only the fields you want to change and everything you omit keeps its current value, so a call carrying just a name will not wipe your bio. An empty string CLEARS a field, which is different from omitting it: an empty value blanks the field, an absent key leaves it alone. At least one of the four is required. It returns ok and updated_fields, and costs $0.0016.
- -The partial behaviour was TESTED before this shipped rather than assumed from the shape of the request. X's own web client sends the whole editable set on every save, so a partial write is a shape its client never produces, which is exactly the kind of thing that silently blanks a field. Name only, against an account with a non-empty bio: HTTP 200, bio intact.
- -updated_fields echoes the field names you SENT. It is not a diff against your previous profile, so a field you set to the value it already held still appears in it. Read the result back with user/info if you need the resulting state.
- -There is no undo and it takes effect immediately on x.com. Read your current values with user/info first if you may need to restore them.
- -Changing an avatar or a header image is a separate pair of endpoints, user/update_avatar and user/update_banner. Both are live; see the entry above.
- -107 endpoints total at the time, 65 reads and 42 writes.
September 13, 2026
Save private drafts and schedule posts, seven endpoints for X's compose surface
Seven endpoints for the part of X most APIs skip. A DRAFT is private and never posts: POST /twitter/draft/create saves one, /twitter/draft/edit replaces its contents, /twitter/draft/delete removes it and GET /twitter/draft/list reads them back. A SCHEDULED post does go out, on its own, at the time you set: POST /twitter/scheduled/create queues it, /twitter/scheduled/delete cancels it before it sends and GET /twitter/scheduled/list shows what is pending. All seven act as your own registered session, never a pool account, because a draft and a queue belong to an account.
- -execute_at is epoch SECONDS, in both directions. X answers the list operation in MILLISECONDS and we normalise it, so a timestamp you read from scheduled/list goes straight back into scheduled/create. A millisecond value sent to create is refused with a message naming the unit rather than scheduling your post tens of thousands of years out, and a past instant is refused too.
- -Both list endpoints can answer with partial: true, which means we read X's reply and did not fully understand all of it. It is deliberately NOT the same as an empty list: on a clean read the flag is absent entirely, so an empty array with no partial means you genuinely have nothing. A response that is partial AND carried no usable row is not billed.
- -thread_truncated on a row means the draft or post is a THREAD and the text you get is only its first tweet. The parse succeeded; the feature is narrower than the data, and saying so is the point.
- -Prices are not uniform across the seven, and two of the higher ones are reads: draft/create, draft/edit, draft/list, scheduled/create and scheduled/list are $0.0016; draft/delete and scheduled/delete are $0.0008.
- -106 endpoints total at the time, 65 reads and 41 writes.
September 5, 2026
List every feedback report your account has filed
GET /feedback returns your own reports, newest first, so an agent that did not keep the id POST /feedback handed back can still find a report and read its status. It completes the three feedback shapes: file one, read one by id, list them all. Free, like its two siblings, and it never touches your X session.
- -Query parameters are limit (1 to 100, default 25), cursor, status (new, triaged, shipped or declined) and type (bug, idea or missing_capability). Anything outside those ranges answers 400 naming the field.
- -Paging is by cursor, not by offset, so a report you file between two calls cannot make a page skip or repeat a row. A cursor this API did not issue answers 400 rather than an empty page, so a corrupted cursor can never look like the end of the list.
- -A list item carries the same fields as GET /feedback/{id} except details and evidence. The body of a report is only ever returned one at a time, so a list can never become a bulk export of everything your account has written.
- -An account that has filed nothing answers 200 with an empty array, never 404.
- -99 endpoints total at the time, 63 reads and 36 writes.
September 4, 2026
Send product feedback from inside your agent, and read back our reply
POST /feedback files a bug, an idea, or a capability we are missing, straight from the tool you are already in. It exists for the AI agents our customers work through: when a tool fails, a capability is missing, or the user asks, the MCP server drafts the report locally, the user reviews it, and the agent sends it. GET /feedback/{id} reads back the status, one of new, triaged, shipped or declined, and the team's reply. Both free, from today.
- -The body is JSON: type (bug, idea or missing_capability), title (up to 120 characters), details (up to 8000, four labelled bullets work best: what happened, what the user said verbatim, repro, evidence), and optionally area, evidence (identifiers only, up to 4096 bytes) and client.
- -Returns 201 with the id. A 400 names the field that was rejected and what would be accepted, so an agent can fix the report and resend without a human reading a stack trace.
- -Served on the public host without the /twitter/ prefix, api.twitterapis.com/feedback, exactly like account/me, because it is proxied straight to billing rather than to X.
- -Rate limited to 10 reports per minute per key. The status endpoint answers 404 for any id that is not on your account, including ids that never existed.
- -99 endpoints total at the time, 63 reads and 36 writes.
August 31, 2026
Replay the webhook deliveries you missed while your endpoint was down
POST /twitter/webhook/{id}/redrive re-queues deliveries that were dead-lettered while your endpoint was unreachable, so they are sent again with a full retry budget instead of being lost. A delivery is dead-lettered after it fails all 8 attempts across 21 minutes, which is what happens when your endpoint is down longer than that window. Free, from today.
- -Bounded by default so a recovered endpoint is not flooded: max_age_hours defaults to 24 (1 to 168) and limit defaults to 100 (1 to 1000), oldest first. Send an empty body to accept both.
- -Returns requeued and skipped_permanent. Deliveries that failed for a permanent reason, a 410 Gone or a webhook you deleted, are not replayed, because they would fail the same way and spend the retry budget again.
- -Replayed events carry the same signature and the same payload as the original, so your handler needs no special case. Make it idempotent on the event id if a duplicate would matter to you.
- -Returns 409 if the webhook is disabled. A webhook is disabled after your endpoint answers 410 Gone, which tells us the destination is gone, so re-register it before replaying.
August 27, 2026
Read back the session you registered with us
GET /twitter/customer/session/status returns the state of the X session stored against your API key, without changing it: which account it resolved to, whether it is live or dead, when it was last used, and whether the proxy you registered is the one your writes leave from. Free, from today. It reads our stored row only, so it never touches X and never consumes an action on your account, which makes it safe to poll in a health check.
- -Returns registered, and false is a real answer rather than an error: it means we hold nothing for your key
- -username and twitter_user_id are read back from storage, not from anything you send, so they settle whether you are posting as the account you think you are
- -status is ok or dead. dead is stamped when X rejects the cookies, so it is an observation rather than a guess, and it is deliberately NOT collapsed into registered:false. A dead session is fixed by re-registering; no session at all is fixed by registering. Different situations, different fixes
- -last_used_at is the field worth alerting on. A timestamp that has stopped moving is usually the first sign of a stalled integration
- -egress.customer_proxy_in_use answers the question people actually ask: is the proxy I supplied the one my writes leave from
- -egress.source names the tier, one of session, sticky_residential, pool_residential or direct, and egress.note says what to do about it. On direct it explains that writes are leaving from a shared server IP, which raises the chance of a challenge, because X ties an account to the IP it acts from
- -It never returns auth_token or ct0, not even a prefix or a hash. It also never returns a proxy URL: your own proxy would be safe to hand back, but with none registered the write path resolves to one of our residential exits whose URL carries our credentials, so the response gives the tier name and a boolean instead of the value
- -Scoped to your own key by construction. It takes no account identifier of any kind, so there is no parameter that could name a different key
- -A read that touches nothing upstream, so it never consumes an action on your X account and is safe to poll in a health check
- -It is a GET on its own path rather than a second method on /twitter/customer/session, because several of our published surfaces key on the path alone and cannot describe two methods on one path
- -99 endpoints total at the time, 63 reads and 36 writes
August 18, 2026
Who follows a List, who runs a community, and how to find one
Three new reads, all standard $0.0008 pooled calls. GET /twitter/list/followers returns the accounts that subscribed to a List, which is a different set of people from its members. GET /twitter/community/about returns a community's moderators and a members preview as FULL user profiles. GET /twitter/community/search is the discovery step the rest of the community family was missing: it finds communities by keyword and hands back the id every other community endpoint needs.
- -GET /twitter/list/followers takes a numeric list_id plus the usual cursor and count, and returns full user objects for every follower on the page
- -Followers are not members. Members are the accounts the List owner put in the List, which is what list/members returns; followers are the accounts that subscribed to read it. The two counts are unrelated, and one captured List carried 557 members against 7 followers, so a small answer here is the normal shape and not a truncated page
- -Pagination on it ends on a null next_cursor rather than on an empty page, so keep following the cursor and stop when it comes back null
- -GET /twitter/community/about takes a community_id and returns moderators plus a members preview, both as FULL user profiles with bio, follower and following counts, tweet count, location, website and join date
- -That is the reason to call it: community/members and community/moderators return a reduced row, so answering who runs a community from those costs one call plus a User Info lookup per person. This answers it in one call
- -Despite the name it carries NO community metadata. There is no description, no rules, no member_count and no join policy on this response, so keep using community/info for those. It is a people endpoint, and it is not paginated because the upstream operation is not
- -members is a preview X caps at 10 rows, so treat it as a sample and page the real roster with community/members. moderators_truncated and members_truncated are read off X's own show-more marker rather than guessed from the row count
- -GET /twitter/community/search takes a query of 1 to 500 characters and a cursor, and searches COMMUNITIES, not posts. To search posts inside one community, use community/tweets
- -Each hit is a compact record, id, name, member_count, is_nsfw, primary_topic, the two banners and the facepile avatars, which is exactly what X's search operation sends and nothing more. Take an id from a hit and call community/info for the rest
- -primary_topic.topic_id is commonly null while primary_topic.name is populated, so key off name rather than treating the null id as an error
- -94 endpoints total at the time, 60 reads and 34 writes
August 17, 2026
Read and write Twitter/X Lists
Five new List endpoints. Two read a public List's posts, and three let you build and maintain a List from code. The reads are pooled $0.0008 calls. The three writes run as your own registered session, because a List belongs to an account: add and remove a member are $0.0008 each, and creating a List is $0.0016.
- -GET /twitter/list/tweets returns the posts of a public List's members from X's search index. It is the filterable read: since and until take YYYY-MM-DD days, until is exclusive, and include_replies toggles replies
- -It does not carry retweets, and X's search index lags brand-new posts, so its result will not match what x.com shows for the same List. Every response discloses source and the exact search_query that was sent
- -GET /twitter/list/timeline returns X's own native List feed instead: members' retweets and X's ordering are both included
- -The two are separate capabilities, not two spellings of one. The native operation takes list_id, count and cursor and nothing else, so no date range or reply filter exists on it, and none is faked on top
- -POST /twitter/list/add_member and POST /twitter/list/remove_member take a numeric list_id and user_id and return the List's member_count after the write. That count is the proof it landed: X returns a populated errors array on successful calls here, so the error array cannot decide the outcome
- -A membership write that did not apply returns the same field layout with a 422 and a machine-readable reason, so one parser handles both outcomes
- -POST /twitter/list/create takes a name plus an optional description and is_private, and returns the new list_id. A List is public unless you set is_private, deliberately: a public List can be made private later, a leak cannot be undone
- -91 endpoints total at the time, 57 reads and 34 writes
August 16, 2026
Read X Communities, and list the quote tweets of any post
Six new reads. Five cover X Communities end to end: the community itself, its member roster, its moderators, its post feed, and every community a given account belongs to. The sixth, GET /twitter/tweet/quotes, lists the quote tweets of a post. All six are standard $0.0008 reads and none of them require a customer session.
- -GET /twitter/community/info returns the community object: name, description, purpose, member and moderator counts, join policy, creation date, the banner media and the rules list
- -GET /twitter/community/members and GET /twitter/community/moderators return the two rosters. Both page on a next_cursor string and carry no total, so an absent cursor is the end of the list
- -GET /twitter/community/tweets returns the community feed and hands back the pinned post as its own field rather than mixed into the list, so you never have to detect it yourself or de-duplicate it
- -GET /twitter/community/memberships takes a user_id and answers which communities that account belongs to, returning the full community object per membership rather than a stub. An account in no communities is an empty list and a 200, not a 404
- -role, can_join, is_pinned and viewer_relationship_type are always null on these reads. Those four describe the viewer rather than the community, and these endpoints answer about the community, so treat them as unset rather than as false
- -The exception is worth knowing: role on a member row is not a viewer field. It is that member's role, it is the same for every caller, and it is the reason the roster endpoints exist
- -GET /twitter/tweet/quotes takes a tweet id or url and returns the quote tweets, with the same cursor and count parameters as tweet/replies
- -Its count is how many quotes this call returned, not the post's lifetime quote total. Read that from quote_count on the tweet object. Expect the two to differ, since quotes that were deleted or made private are not returned
- -Pass strict=true to receive only rows whose quoted post is confirmed to be the one you asked for
- -86 endpoints total at the time, 55 reads and 31 writes
August 16, 2026
Ask X's own Grok, and get the pages it cited
POST /twitter/grok/chat puts X's in-app Grok behind an API call. Unlike a general-purpose model API, Grok reads X in real time and hands back the web pages its answer used, so you can see what it read, not just what it said. Pass a bare tweet URL as the message and you get a structured summary of that post. GET /twitter/grok/config tells you whether your account is eligible and which models it may use. Chat is a premium $0.0040 call, at the same tier as full thread expansion; the config read is free.
- -POST /twitter/grok/chat takes message (the prompt) or messages (prior turns) and returns { ok, conversation_id, response_id, answer, citations, citation_count, tool_calls, requested_model, model, mode }
- -citations are the pages the answer used, each with url, domain, title and snippet. They accumulate across every search Grok runs in one answer, not just the last one, and repeated urls are collapsed
- -tool_calls show what Grok actually searched for, so you can see the queries behind an answer
- -The reply is buffered into one JSON response, not streamed, so it behaves like every other endpoint here
- -It is stateless: we store no conversation, no turn and no prompt text. Pass conversation_id and the prior turns back to continue
- -mode is auto, fast or expert. model comes back alongside requested_model because auto resolves at X's end, so asking for grok-4-auto can be answered by grok-4
- -Both endpoints run as your own authenticated account, so Grok eligibility and Grok usage caps are the ones on that X account
- -GET /twitter/grok/config returns eligibility, X's own ineligible_reasons, the default model, and the full model option list
- -80 endpoints total at the time, 49 reads and 31 writes
August 16, 2026
Read an X Space, and set an article's cover image
Two additions in one release. GET /twitter/spaces/info returns everything X exposes about a Space, live or ended: title, host, speakers, topics, timing and audience counts. POST /twitter/article/update_cover_media attaches an already-uploaded image as an article's cover, closing the last gap in the article write set. Spaces info is a standard $0.0008 read; the cover update is $0.0016, matching the other article writes.
- -GET /twitter/spaces/info?id=1RKZzjkoYRAKB returns { space } with title, state, content_type, host, topics, the wrapper tweet, and the admin, speaker and listener rosters
- -state is Scheduled, NotStarted, Running or Ended, so the same endpoint works before, during and after a Space
- -An ENDED Space returns an empty listeners array: X does not keep the per-person roster once a Space finishes. The audience is still there as total_live_listeners (peak concurrent) and total_replay_watched, and admins and speakers survive
- -Every timestamp is a millisecond-epoch number, started_at and ended_at included, so you can subtract them directly
- -A Space where the host enabled video comes back with content_type visual_audio, everything else identical
- -POST /twitter/article/update_cover_media takes id and media_id. Upload the image with media/upload first, then attach it: this endpoint attaches, it does not upload
- -spaces/info returns metadata only, not the Space audio
- -78 endpoints total at the time, 48 reads and 30 writes
August 16, 2026
Check whether an account is alive, suspended, or deleted
A new GET /twitter/user/status endpoint answers in one call whether a handle is alive, suspended, gone, or something X will not explain. It separates a suspended account from a deleted one and from a handle that never existed, each of which a profile lookup reports as a plain 404. Standard $0.0008 read.
- -GET /twitter/user/status?userName=openai returns { userName, status, id, reason }
- -status is one of alive, suspended, not_found, or unavailable
- -Every outcome is an HTTP 200: a suspended account is a successful answer, not an error, so you branch on the status field instead of on a status code
- -reason carries X's own wording when it gives one, so an account state we do not map is visible rather than being rounded to alive
- -A protected (private) account is alive: protection is a visibility setting, not an account state
- -76 endpoints total at the time, 47 reads and 29 writes
August 15, 2026
Account-wide monitor health rollup
A new GET /twitter/monitor/health endpoint returns your whole monitoring setup in one call, service status, active/paused monitor counts, and the last 24 hours of delivery outcomes, instead of listing your monitors and calling the per-monitor health endpoint on each one. Free, same as every other Monitoring route.
- -GET /twitter/monitor/health: no path parameter, account-wide, never 404s (a key with zero monitors gets zeroed counts back)
- -Distinct from GET /twitter/monitor/{id}/health, which stays for a single monitor's cursor detail
- -75 endpoints total at the time, 46 reads and 29 writes
August 14, 2026
Compatibility monitor endpoints under /oapi/x_user_stream
Three compatibility routes that accept a third-party x_user_stream request and response shape and drive the same monitors the native /twitter/monitor endpoints do. Same underlying feature, a second URL shape for teams migrating an existing integration built against that shape.
- -POST /oapi/x_user_stream/add_user_to_monitor_tweet: watch an account, third-party request/response shape
- -POST /oapi/x_user_stream/remove_user_to_monitor_tweet: stop watching an account
- -GET /oapi/x_user_stream/get_user_to_monitor_tweet: read the monitor's current state, no query params, matching the third-party spec it mirrors
- -74 endpoints total at the time, 45 reads and 29 writes
August 13, 2026
Account monitoring and webhooks are live
Watch an X account and get a signed webhook POST the moment it posts, instead of polling for new tweets yourself. Register a webhook destination, point a monitor at it, and new posts arrive automatically. Pause, resume, or test a webhook delivery on demand. All 9 monitoring endpoints are free and do not consume credits.
- -POST/GET /twitter/webhook: register a delivery URL, get a one-time HMAC-SHA256 signing secret back
- -POST/GET /twitter/monitor: watch an account by handle; no backfill, only posts after creation are delivered
- -POST /twitter/monitor/{id}: pause, resume, or repoint an existing monitor's webhook
- -POST /twitter/webhook/{id}/test: fire one real signed test delivery right now and see the result immediately
- -DELETE /twitter/monitor/{id} and DELETE /twitter/webhook/{id} to stop watching or remove a destination
- -GET /twitter/monitor/{id}/health: check a monitor's poll cursor and whether events may have been missed
- -GET /twitter/monitor/deliveries: the actual delivery history behind a monitor, status, detection lag, and delivery lag per event
- -A flat per-account cap on active monitors applies
- -71 endpoints total at the time, 44 reads and 27 writes
August 11, 2026
Batch user lookup taken out of service
GET /twitter/users/by_ids is retired. X no longer serves the batch lookup this endpoint depended on. The route stays reachable and returns a clear 503 rather than silently failing, but it is no longer documented or priced as a working endpoint.
- -GET /twitter/users/by_ids now returns 503 endpoint_unavailable on every call
- -Use GET /twitter/user/info_by_id instead: same user object, one id per call
- -Removed from the docs reference, the OpenAPI spec, the pricing tables, llms.txt, and the MCP tool list
- -61 endpoints total at the time, 40 reads and 21 writes
August 10, 2026
Read your bookmark folders, and the tweets inside one
Two new endpoints for X's bookmark folders (X's internal name: collections), the named groups you can organize saved tweets into, separate from your flat All Bookmarks list. List your own folders, or read the tweets inside one specific folder.
- -GET /twitter/user/bookmark_folders returns your own folders: id, name, and a cover image
- -GET /twitter/user/bookmark_folder_timeline?folder_id= returns the tweets inside one folder, cursor-paginated
- -Both are customer-session reads, same auth model as the existing bookmarks and bookmark_search endpoints, and bill at the standard $0.0008 rate
- -62 endpoints total at the time, 41 reads and 21 writes
August 10, 2026
X Articles: create, edit, publish, and read long-form posts
Eight new article/* endpoints cover the full lifecycle of X's long-form Articles feature (X's internal name: Notes): create a draft, set its title and content, publish it (posts a real announcement tweet), unpublish, delete, list your own articles by lifecycle, and read a published article publicly via its announcement tweet.
- -POST /twitter/article/create, POST /twitter/article/update_title, POST /twitter/article/update_content, POST /twitter/article/publish, POST /twitter/article/unpublish, POST /twitter/article/delete, GET /twitter/article/list, GET /twitter/article/get
- -Every write acts as the account behind your registered session, exactly like tweet/create, and accepts the same per-call inline x-auth-token/x-ct0 credentials
- -article/get is the one public read: no session or credentials needed, just your API key, same auth model as tweet/detail
- -Publishing is a real, public action, it posts an announcement tweet that is visible immediately; unpublish reverts to draft but leaves the tweet up, delete on a published article removes the tweet too
- -60 endpoints total at the time, 39 reads and 21 writes
August 9, 2026
Revoke your stored session yourself
POST /twitter/customer/session/delete deletes the auth_token and ct0 you registered against your API key. No ticket, no email, no human in the loop. The call is free.
- -POST /twitter/customer/session/delete, authenticated with your own API key and taking no parameters
- -Scoped to the caller by construction. The key comes from the authenticated request, never from the body or the query string, so a key cannot reach another account's session
- -Idempotent, and 200 either way. It returns deleted true when a stored session was removed and deleted false when there was nothing to remove, so calling it twice is not an error
- -Free, and that is a security property rather than a discount. Pricing this at zero is what makes sure a customer out of credits can still delete their own credentials
- -It deletes our stored copy only. It does not log the account out of x.com, so revoke the session in your X account settings as well if you want the cookies themselves killed
- -Credentials passed per call as the x-auth-token and x-ct0 headers were never stored, so there is nothing to revoke for that mode and it returns deleted false
August 2, 2026
Blocking and muting lists are live
Read the accounts your own authenticated account has blocked or muted, returned as full user objects with cursor pagination. Both are standard reads at $0.0008 per call.
- -GET /twitter/user/blocking, the accounts you have blocked
- -GET /twitter/user/muting, the accounts you have muted. Muting hides someone's posts without blocking them, so the two lists differ and an account can sit on one and not the other
- -These read your own lists only. X offers no way to read another account's block or mute list, so there is no user_id parameter
- -An empty users array means you block or mute nobody. A list we cannot read comes back as an error status instead, so an empty page is never a silent failure
- -$0.0008 per call, cursor paginated
August 2, 2026
User About returns protected status and affiliate label
GET /twitter/user/user_about now tells you whether an account is protected, and returns the affiliate label X shows on accounts tied to a verified organization. Price is unchanged at $0.0008 per call.
- -protected, true when the account's posts are visible to approved followers only
- -affiliate_label, the parent organization X displays on an affiliated account
- -Purely additive. Existing parsers keep working untouched
August 2, 2026
MCP server 0.6.3 ships 51 tools, one per endpoint
The @twitterapis/mcp Model Context Protocol server now exposes every endpoint as a native tool, including trends, batch user lookup, media readiness, and the new blocking and muting lists. The tool catalog is generated from the published API spec, so every endpoint has a matching tool.
- -Install: npx -y @twitterapis/mcp@latest
- -51 tools, one per endpoint, generated from the same OpenAPI spec the REST API publishes
- -Tool descriptions call out the real gotchas, for example that media uploads process asynchronously
- -Registry descriptors ship with the package, so MCP client directories can list it
- -Every call bills at the same rate as the REST endpoint behind it
August 2, 2026
Twelve new pages: free tools, SDK guides, status, integrations
Four browser tools that need no API key, SDK quickstarts for Node, Python and Go, a public status page, an integrations directory, and an about page.
- -/tools, carrying Twitter ID Finder, Tweet Counter, Follow Checker and an Engagement Calculator. No signup and no key needed
- -/sdk with /sdk/node, /sdk/python and /sdk/go, copy-paste clients per language
- -/status, endpoint health in one place
- -/integrations, what TwitterAPIs plugs into
- -/about, who runs this and how it is operated
August 2, 2026
Stored credentials are encrypted at rest
Every credential we store is now encrypted with AES-256-GCM before it reaches the database, including the auth_token and ct0 of the customer sessions you register with us.
- -AES-256-GCM authenticated encryption, so a tampered ciphertext fails to decrypt instead of returning altered data
- -Covers customer_sessions auth_token and ct0, the credentials you hand us when you register a session
- -No API change and nothing to update in your integration
July 31, 2026
Batch user lookup is live
Resolve up to 100 numeric user IDs into full profiles in a single call instead of looping the single-user endpoint. The common case is hydrating the authors of a batch of tweets.
- -GET /twitter/users/by_ids, up to 100 ids per call
- -Returns the same user object as /twitter/user/info_by_id, as a list
- -IDs that no longer resolve, from suspended or deleted accounts, are omitted rather than returned as nulls. Diff the ids you sent against the ids you got back to see which were dropped
- -Sending more than 100 ids is rejected rather than silently truncated
- -Bills per resolved user at the standard $0.0008 rate
July 24, 2026
Media processing status is live
Check whether an uploaded media_id has finished processing on X before you attach it to a tweet. Video, GIF and large uploads process asynchronously, so an upload that already returned a media_id is not necessarily ready to post.
- -GET /twitter/media/status?media_id=<id>
- -Returns state as pending, in_progress, succeeded or failed, plus progress_percent
- -check_after_secs carries how long X wants you to wait before polling again. Honour it rather than tight-looping
- -An error object comes back when state is failed, so a rejected upload is visible instead of silent
- -$0.0008 per call
July 21, 2026
User About returns account origin fields
GET /twitter/user/user_about now reports where an account is based, what it signed up through, and how many times it has changed handle. These are the fields most people want for account-age and authenticity checks. No price change.
- -account_based_in, the country X attributes the account to
- -created_via, the client the account was created through
- -username_changes, how many times the handle has changed
- -Purely additive. Existing parsers keep working untouched
July 20, 2026
Trends API is live
Fetch the current top X trends for any country or city, with a companion endpoint that lists every location trends can be served for. $0.0008 per call, the same as any standard read.
- -GET /twitter/trends, top trends for a location. With no location it returns Worldwide
- -Pass country as an ISO code or a country name, for example US or Japan, or pass a numeric woeid. woeid wins when you send both
- -GET /twitter/trends/locations, every location trends are available for, with its woeid
- -The response carries the resolved location and the as_of timestamp, so you always know what was measured and when
- -A location X will not serve returns a 400 rather than a misleading empty list
July 20, 2026
Account and login endpoints on the main API host
The free account endpoints are now served from the same host as the rest of the API, and the login endpoint answers on a shorter path. One base URL for everything.
- -GET /account/me and GET /account/payments answer on the public API host. Still free, still 30 requests per minute
- -POST /twitter/user_login now works as an alias for /twitter/user/user_login. Both paths are served, so nothing you have already written breaks
July 5, 2026
Write, DM and session endpoints are documented
Reference pages and OpenAPI coverage now include posting and deleting tweets, direct messages, and the reads that run on your own session.
- -tweet/create and tweet/delete
- -dm/list, dm/conversation and dm/send
- -home_timeline, bookmarks, bookmark_search, likes and followers_you_know
- -media/upload, plus user/tweets/complete
- -Copy-paste examples corrected to the live contract, including the /twitter/ path prefix and the id parameter
- -public/openapi.json is generated from the same source the docs read, so the spec and the reference pages cannot drift apart
June 29, 2026
One canonical price table, simple writes cut to the read rate
Every endpoint moved onto a single price table. Simple write actions dropped to the standard read rate, and the two endpoints that expand a whole thread or a whole timeline moved up to reflect the work they do.
- -Like, unlike, retweet, unretweet, bookmark, unbookmark, follow, unfollow, delete tweet and media upload: $0.0015 down to $0.0008, the standard read rate
- -Direct messages, tweet creation and profile updates: $0.0015 up to $0.0016
- -GET /twitter/tweet/thread: $0.0008 up to $0.004, because it resolves a tweet to its root and walks the entire self-thread
- -GET /twitter/user/tweets/complete: $0.0008 up to $0.0024, because it expands self-threads across a whole page of results
- -Standard reads were not touched and stayed at $0.0008
June 11, 2026
User Tweets Complete endpoint is live
Fetch a user's recent tweets-and-replies timeline with self-thread expansion, so thread continuations inside the recent window come back more completely than the standard /user/tweets page. $0.0024 per call, 40 raw items per page before expansion.
- -GET /twitter/user/tweets/complete?userName=<handle>&cursor=<optional>
- -Expands detected self-threads (capped at 20 roots per page; `complete` flags when the cap is exceeded)
- -$0.0024 per call (vs $0.0008 for the standard /user/tweets page), priced for the extra thread-expansion work
- -Expanded threads can overlap adjacent pages, dedupe by tweet `id` when paginating with next_cursor
June 11, 2026
Tweet Thread endpoint is live
Resolve a full linear self-thread from any tweet in it, pass any tweet ID and get the ordered thread back, walking only the original author's linked replies. $0.004 per call.
- -GET /twitter/tweet/thread?id=<tweetId>
- -Works from any tweet in the thread, resolves to the root, then walks the author's self-replies in order
- -No auth_token parameter required. Your API key is all you need.
- -Response flags when a very long thread is truncated at the pagination cap
June 10, 2026
Tweet Retweeters endpoint is live
Fetch the full list of users who reposted (retweeted) any tweet. $0.0008 per call, ~20 users per page with cursor pagination.
- -GET /twitter/tweet/retweeters?id=<tweetId>&cursor=<optional>
- -No auth_token parameter required. Your API key is all you need.
- -Returns tweetId, user_count, has_more, next_cursor, and a users array with full profile data (followers, verified status, bio, location, etc.)
- -Paginate by passing next_cursor until has_more is false
May 31, 2026
Twitter / X MCP Server now available on npm
The official @twitterapis/mcp Model Context Protocol server is now published on npm and open-sourced on GitHub. Plug the Twitter/X read API into Claude Desktop, Cursor, Cline, or any MCP-compatible client with a one-line install. Calls bill at the standard TwitterAPIs rate of $0.0008 per read.
- -Install: npx -y @twitterapis/mcp@latest
- -Drop a small config block into claude_desktop_config.json or the Cursor MCP settings panel, restart the client, and the tools appear
- -Read tools map onto TwitterAPIs read endpoints: tweet/advanced_search, tweet/detail, tweet/replies, tweet/thread, user/info, user/tweets, user/mentions, user/followers, and more
- -Open-sourced on GitHub at github.com/TwitterAPIs/twitterapis-mcp
- -Full value prop, code samples, and FAQ at /mcp
May 6, 2026
Referral program is live
Earn 20% lifetime commission on every payment from anyone you refer. Open to every TwitterAPIs user, your unique referral link is generated automatically.
- -20% of gross on every payment from referred customers, lifetime
- -$5,000 / calendar year cap per affiliate
- -30-day pending holdback before commission becomes available
- -Convert available earnings to API credits with a +15% bonus
- -Find your link and balance at /dashboard/referrals
April 1, 2026
Account Info & Payment History endpoints
Two new free endpoints to check your TwitterAPIs account details and payment history. No credits deducted, rate limited to 30 requests per minute.
- -GET /account/me, credit balance, usage summary, account details
- -GET /account/payments, payment/top-up history
- -Free to use, no credits consumed
- -Rate limited: 30 requests/min per API key
March 31, 2026
User Affiliates endpoint is live
Get affiliated accounts of verified organizations (companies, brands, nonprofits). Returns ~20 users per page with cursor pagination. $0.0008 per call (~20 tweets).
- -GET /twitter/user/affiliates
- -Returns affiliated accounts of verified organizations
- -Cursor-based pagination (~20 users per page)
- -Includes full profile data for each affiliate
March 16, 2026
Search Users endpoint is live
Search for Twitter/X users by keyword, username, or topic. Equivalent to the "People" tab in Twitter search. $0.0008 per call (~20 tweets).
- -GET /twitter/user/search
- -Search by keyword, username, or topic
- -Returns up to 20 users per page with full profile data
- -Cursor-based pagination support
March 14, 2026
Blog is live
TwitterAPIs now has a blog. Read guides, tutorials, and comparisons to get the most out of the Twitter API.
- -SEO-optimized blog pages with structured data
- -Syntax-highlighted code snippets with copy button
February 22, 2026
Followers v2 & Following v2 endpoints
Two new endpoints. $0.0008 per call (~50 tweets).
- -GET /twitter/user/followers_v2
- -GET /twitter/user/following_v2
February 11, 2026
Payment integration is live
You can now purchase API credits directly from the dashboard via Stripe. Two credit packs are available, $10 and $50. No subscriptions, no recurring charges. Credits are added instantly and never expire.
- -Secure one-time payments powered by Stripe
- -$10 Starter pack (~10,000 API calls) and $50 Pro pack (~50,000 API calls)
- -Credits added to your account instantly after payment
- -Payment history visible in your dashboard under Credit History
February 9, 2026
TwitterAPIs public launch
TwitterAPIs launched publicly with the cheapest pay-as-you-go Twitter/X API pricing on the market. $0.0008 per call (~20 tweets) for every endpoint, and $0.50 in free credits for every new account.
- -21 API endpoints covering tweets, users, search, and lists
- -Pay-per-call pricing with no subscriptions or monthly fees
- -99.9% uptime SLA with sub-2-second response times
- -Full API documentation at docs.twitterapis.com
Next read
Continue exploring TwitterAPIs:
TwitterAPIs pricing
Endpoint-level costs and per-call totals.
Twitter API pricing comparison
Monthly economics and request-level cost side by side.
Twitter scraper API
Scrape tweets, profiles, and followers at $0.04 per 1,000.
TwitterAPIs MCP server
Wire the full Twitter API into Claude, Cursor, and Cline.