X (Twitter) Profile Scraper

Turn a list of X handles into a clean table of accounts. Each row says who the account claims to be, how big its audience is, when it joined, where it points people, and whether it carries a verification mark today.

No X login, cookie or session is involved at any point in a run. Nothing has to be connected, and no account of anyone's is put at risk to read a public profile.

Bare handles, @handles and pasted profile links are all accepted, and a single list may mix them.

Accepted input

handles is required and takes one or more accounts. maxItems caps how many rows are saved and defaults to 100; setting it to 0 removes the cap and runs the whole list.

{
  "handles": ["nasa", "@SpaceX", "https://x.com/ISS_Research"],
  "maxItems": 100
}

Response fields

One row per account that resolves.

Field	Contents
user_id	X's numeric identifier for the account, as a string
handle, requested_handle	X's casing of the handle, and the value the run asked with
name, bio	Display name and bio
profile_url	Link to the profile
location	Free text the account entered; not geocoded and not an address
website	The link in the profile header, as the account stated it
joined_at	Account creation time, in X's own date format
followers_count, following_count	Audience size, and how many accounts it follows
tweet_count, media_count, listed_count	Posts, posts carrying media, and public lists including the account
favourites_count	Posts the account has liked, in X's own spelling
verified, is_blue_verified	Legacy check and current mark
protected	Whether posts are restricted to approved followers
profile_image_url, profile_banner_url	Avatar and header image
professional	X's business-account object, whole; null on ordinary accounts

{
  "user_id": "11348282",
  "handle": "NASA",
  "requested_handle": "nasa",
  "name": "NASA",
  "profile_url": "https://x.com/NASA",
  "bio": "Making the seemingly impossible, possible. ✨",
  "location": "Pale Blue Dot",
  "website": "https://t.co/9NkQJKAVks",
  "joined_at": "Wed Dec 19 20:20:32 +0000 2007",
  "followers_count": 92309202,
  "following_count": 119,
  "tweet_count": 74339,
  "verified": false,
  "is_blue_verified": true
}

Questions that come up

Why do verified and is_blue_verified disagree?

Because they are two different questions, and on most currently verified accounts the answers differ. On the account sampled above, verified is false while is_blue_verified is true. verified is the pre-2023 legacy check; is_blue_verified is the current mark, and it is the field to read for a single answer. I publish both rather than merging them into one boolean, because a merge would destroy the distinction and reading verified alone returns the wrong answer for most accounts that carry a mark today.

Which column joins back to the input list?

requested_handle. X returns handles in its own casing, so a request for nasa produces NASA in the handle field. requested_handle echoes the value supplied, reduced from an @handle or a pasted profile link, so a join against an input list never depends on two sides agreeing about normalisation. For anything tracked over time the key is user_id, which survives a rename; the handle does not.

Is location a real place?

No. It is free text the account typed into the profile field, and nothing geocodes it, here or upstream. Pale Blue Dot is a genuine value from the account sampled above. Treat the column as a string, not as an address, and expect jokes, place names and nulls in the same column.

Does tweet_count predict how many posts an export will return?

No, and using it as a budget is the most common way to plan a run badly. It is how many posts X states the account has made. A timeline walk I measured reached 122 posts over eight pages and was still being offered more, so the reachable depth is a floor rather than a number this field predicts. tweet_count describes an account; it does not size an export.

What comes back for a protected account?

Its public record, in full, with protected set to true on the row. A profile is public even when the posts behind it are not. The timeline is a separate matter and is not readable, since this Actor holds no X account and follows nobody.

What happens to a handle that is wrong or retired?

A handle outside X's own rule of 1 to 15 letters, digits or underscores is reported in the run log and skipped before a request is spent on it. A handle that does not resolve to any account is likewise reported and skipped, because X answers an unknown account as a normal empty response rather than as an error and there is nothing to retry. The remaining accounts in the list are still collected. Duplicates are collapsed before any request is made, so nasa, @NASA and https://x.com/nasa in one list are one account and one charge.

Why are profile_banner_url and professional sometimes null?

Because the account never set a header image, and because the account is not a business account. Fields absent from the upstream response are returned as null rather than omitted, so every row has the same shape and a column never disappears mid-export. professional is republished whole rather than flattened, since its shape varies by account type.

Does profile_image_url give the full-size avatar?

It gives the URL exactly as X states it, which usually carries a _normal size marker. It is not rewritten to a larger variant, because that would be a guess about a CDN path rather than a value anyone measured. The same restraint applies to website, which is often an X short link on accounts that set it recently and is not followed or expanded here.

Can follower and following lists, search results, or an account's media tab be collected?

No, and not by any setting. Each of those needs a logged-in X account, and this Actor holds none. That is the trade for an Actor that asks for no login, no cookie and no session, and it is a measured boundary rather than something still to be built. The counts themselves are published: followers_count, following_count, media_count and listed_count all arrive on the row, and a post's media arrives with the post itself, inside that post's entities.

Are followers_count and the other counts stable between runs?

No. They are live counters, and two reads minutes apart will differ. That is drift rather than a fault. joined_at is the only fixed value on the row, and it is left in X's own date format rather than rewritten to ISO 8601, because rewriting a timestamp is how a timezone bug gets into data that did not have one.

If a field returns null where a value is clearly present on x.com, the Actor's Issues tab is the fastest way to reach me; a handle in the report is usually enough to reproduce it.

Related Actors

X (Twitter) Tweets Scraper exports what these accounts posted, taking the same handles this Actor takes and paging each timeline by cursor. X (Twitter) Post Scraper takes post links directly and returns one row per post, which is the shorter route when specific posts are already known.