OSINT on Twitter (X): What Public Data You Can Pull, and How

An X account exposes a fixed set of public facts. Each row below is one question an investigator asks, the data point that answers it, the free tool on this site that shows it for one handle, and the API route for doing it at scale. Endpoint paths are relative to https://api.twitterapi.io; every one of them is a GET with the X-API-Key header and returns JSON.

Two things the table does not contain, because X does not expose them publicly: a user's real-time position (X removed precise coordinates from its apps in 2019 and the location string is free text), and anything about a protected account beyond the fact that it is protected. The posts of protected accounts are not returned by any read endpoint here.

The two most useful facts about an account are also the two least expensive to get: the creation timestamp and the numeric user ID. Both come from one call, GET /twitter/user/info?userName=<handle>, which puts the profile in data with camelCase fields: id, userName, name, createdAt, followers, following, statusesCount, location, description, isBlueVerified, protected, isAutomated (twitterapi.io docs, verified 2026). Profiles are billed at $0.18 per 1,000, so a watch-list of 500 handles costs $0.09 to refresh.

Creation date. data.createdAt is the moment the account was registered. On its own it answers "is this a fresh account?"; across a set of accounts it answers "were these created together?", which is the usual first step when a cluster of profiles pushes the same message. A posts-per-day lifetime average (statusesCount divided by age in days) is a second cheap signal from the same call. Treat both as leads: a brand-new account can be a real person who just joined, and an old one can be bought or renamed into a copy of someone else. For a single handle the free account age checker on this site shows the exact timestamp, the age in years and days and the username change count without an API key.

User ID. data.id is the string of digits X assigned at registration. X's own help page on changing a username states that a change does not affect followers, direct messages or replies, which is another way of saying the account underneath is the same object; the ID is that object's name. Store IDs, not handles, in any case file: x.com/i/user/<id> opens the profile whatever it is called today, and GET /twitter/user/batch_info_by_ids?userIds=<id1>,<id2> returns the current userName for a list of IDs in one call. The free ID finder converts in both directions for one handle at a time. The reverse lookup is what lets you prove that the handle a screenshot shows and the handle in front of you today are the same account, or that they are not.

Rename history. GET /twitter/user_about?userName=<handle> returns the panel X shows under About this account: about_profile.username_changes.count, the account_based_in region, a location_accurate flag and an affiliate_username for organisation-affiliated accounts. X rolled this panel out globally in November 2025 (announced by its head of product on X). The change count tells you an account has been renamed; it does not tell you the previous names, which X does not publish.

Every post, user and direct message ID on X is a 64-bit Snowflake ID, and the high bits of a Snowflake ID are a timestamp. X's developer documentation describes the IDs as unsigned 64-bit integers composed of a timestamp, a worker number and a sequence number, which makes them roughly time-ordered: higher IDs are newer objects (docs.x.com, X IDs). The original generator, published by Twitter and archived at github.com/twitter-archive/snowflake, states the layout: 41 bits of milliseconds since a custom epoch, 10 bits of machine ID (5 datacenter + 5 worker in IdWorker.scala), and a 12-bit sequence. The custom epoch in that file is twepoch = 1288834974657, which is 2010-11-04 01:42:54.657 UTC.

The formula: unix_ms = (tweet_id >> 22) + 1288834974657. Shift the ID right by 22 bits (12 sequence + 5 worker + 5 datacenter) to drop the machine and sequence fields, add the epoch, and you have the publication time in milliseconds, with no API call and no rate limit. Worked example: ID 2109793921203093888 shifted right by 22 is 503014068890; add the epoch and you get 1791849043547 ms, which is 2026-10-12 23:50:43.547 UTC. The same arithmetic works on user IDs created after November 2010, which gives you a second, independent estimate of an account's creation time to check createdAt against.

Two caveats. IDs at or below 29700859247 predate Snowflake and are plain sequential numbers, so they carry no time; the script returns None for them. And the timestamp is when X assigned the ID, which for a scheduled post is the publish moment, not the moment the author wrote it. For bulk work paste a list of URLs or IDs into the free tweet timestamp tool on this site, which does the conversion, shows your local time next to UTC and exports CSV; for code, the function below is the whole thing.

Two endpoints return the graph. GET /twitter/user/followers?userName=<handle> returns the account's followers newest-first, and GET /twitter/user/followings?userName=<handle> returns who it follows; both page with cursor and pageSize (up to 200), both return has_next_page and next_cursor at the top level, and both carry a full profile per user in snake_case: id, screen_name, name, followers_count, friends_count, statuses_count, created_at, location, description, protected, verified (twitterapi.io response shapes, verified 2026). Note the casing: these lists use screen_name and created_at, while /twitter/user/info uses userName and createdAt. Followers and followings are billed at 1 to 3 credits per user returned, so a full first page of 200 costs between $0.002 and $0.006.

The graph questions practitioners ask are set operations: which accounts do two suspects both follow, which of an account's newest followers were themselves created this month, and which accounts in a follower list share a creation week and an empty bio. All of them key on the permanent id, never on the handle. Keep the raw lists as CSV with the ID as the first column; graph tools such as Gephi or Maltego import a two-column edge list directly, and the ID column is what lets you merge a list pulled today with one pulled next month after half the handles have changed.

The newest-first ordering of /twitter/user/followers is itself a signal: the first page is the most recent follows, which is where a sudden purchase of followers or a coordinated follow wave shows up as a run of accounts with adjacent creation dates. A follower audit that scores that first page is the subject of the Twitter audit guide linked below.

Posting-time patterns. GET /twitter/user/last_tweets?userName=<handle>&includeReplies=true returns the account's most recent posts, newest first, with the list nested at data.tweets and the pagination fields has_next_page and next_cursor at the top level. Each post carries createdAt in the classic format Tue Dec 10 07:00:30 +0000 2024, always with a +0000 offset, so parsing with %a %b %d %H:%M:%S %z %Y and reading .hour gives UTC hours directly. Bin a few hundred posts by hour and you get a histogram like the one below. Hour-of-day histograms are commonly used by practitioners to estimate the time zone an account operates in and to spot accounts that post around the clock with no sleep gap; the inference is weak for scheduled or multi-operator accounts, and a quiet band can be a work shift rather than a night, so calibrate it against accounts whose time zone you already know before you rely on it. Timeline pages are billed at $0.15 per 1,000 posts, so 400 posts (20 pages) cost $0.06.

GET /twitter/tweet/advanced_search takes a query string in the same grammar as the X search box, a queryType of Latest or Top, and a cursor (empty string for the first page). Each page returns up to 20 posts in a top-level tweets array with has_next_page and next_cursor; every post carries id, createdAt, text, likeCount, retweetCount, replyCount, viewCount, isReply, source and an author object with userName, id, location and createdAt. Billing is $0.15 per 1,000 posts returned with a 15-credit ($0.00015) minimum per request, so a full page costs $0.003 and an empty one $0.00015.

Keep queries under 512 characters: X's own operator reference gives 512 as the self-serve limit for recent search and 1,024 for the full archive (docs.x.com, verified 2026), and in practice that is about 20 from: clauses OR-ed together. The official reference documents from:, to:, url:, lang:, is:retweet, has:geo, place: and point_radius: for its own API; the search-box grammar accepted here is broader, including since: / until:, min_faves: and the filter: family, and the full list is on the search operators reference linked below.

Location. Four location signals exist and none is complete: a Place tag on the post (rare), the free-text profile location string on every author object, the account-based-in label from /twitter/user_about, and place names in the text. For an account you can read the first three from the responses above; for a search, bin results by author.location rather than trusting a near: operator. The search-by-location guide linked below walks through all four, with the control-query check that tells you when an operator was silently ignored.

This is the question every OSINT page gets asked and most answer badly, so here is the plain version: no read endpoint on twitterapi.io, and no endpoint on the official X API, returns a post that X no longer serves. When you call GET /twitter/tweets?tweet_ids=<id> for a deleted post the call succeeds and tweets is empty; when you call GET /twitter/user/info for a deleted or suspended account the call returns status: "error" and msg: "user not found" with data null, and never an HTTP 404. A suspended account that still exists comes back with unavailable set. Anything that claims to "recover" a deleted post is reading a copy someone saved earlier: a web archive, a quote-post that embedded the text, or a scheduled capture.

Edited posts are similar. X allows up to five edits inside a short window after posting (one hour per the X help center; the X API documentation describes each edit as creating a new post ID and lists the chain in edit_history_tweet_ids). The tweet objects returned here are the version X currently serves and do not include that chain, so a post you fetch after an edit is the edited one. If the original wording matters, you need the copy you took before the edit.

The only reliable record is therefore one you make yourself, on a schedule, before the post disappears. The simplest form is a search bound to the last run: from:handle since_time:<last_run_unix> on /twitter/tweet/advanced_search, stored as JSON with the post id, createdAt, text, the author.id and the snowflake time you computed. A check that finds nothing costs the 15-credit minimum, $0.00015, so polling one query every 5 minutes for a month is $1.30 and every 60 seconds is $6.48, plus $0.15 per 1,000 posts actually captured. Capturing the id matters more than it looks: a later GET /twitter/tweets on a stored ID that now returns nothing is itself evidence that the post was removed between the two timestamps. For what remains visible after an account is deleted, deactivated or suspended, see the guide on finding deleted Twitter accounts linked below.

Every data point on this page can be reached three ways. The differences are setup, cost at volume, which operators you can use and how far back you can go.

The ratios are arithmetic from the two published price lists, not a benchmark. What the official route buys you is official support and the documented operator set; what it costs you is the approval step and about 33 times the price per post. The by-hand route stays the right one for a single account you will look at once; the moment the question becomes "these 200 accounts, every week", it is an API job, and the dossier script below is the starting point.

Public data only. Every field on this page is one X displays to anyone viewing the profile or running a search. Nothing here reads direct messages, protected accounts' posts, email addresses or phone numbers, and the read endpoints cannot: a protected account's timeline is simply not returned. If a method needs a password, a session cookie from someone else's account, or a phishing page, it is not OSINT and it is not covered here.

No account takeover, no impersonation, no interference. Reading public data needs no X login. Do not log into the account you are investigating, do not create look-alike accounts to approach it, and do not use what you find to contact, harass or dox the person behind it. Keep automated reads at a sensible pace; the rate limits above are the ceiling, not a target.

Respect X's terms and the law where you operate. X's Terms of Service and developer rules govern access to the platform, and data protection law (the GDPR for EU residents' data, state laws in the US) applies to personal data regardless of how public it was. Collect the minimum the question needs, record why you collected it, delete what you do not need, and keep a chain of custody (timestamp, source URL, raw JSON) for anything that may be used as evidence.

A signal is not a finding. A creation date, a quiet band in a histogram, a shared set of followings, or a profile location that matches a city are each consistent with several explanations. Corroborate across independent signals and outside sources before attributing an account to a person, and never publish an attribution you cannot defend. The tools on this page make the data cheap; the judgement is still yours.