Threads Profile Scraper

The Actor retrieves one public Threads account by username and returns its profile record: display name, bio, follower count, verification, avatar, and the topic tags Threads shows on the account. It accepts a bare username, an @handle, or a full profile URL.

Accepted input

Field	Type	Default	Description
username	string	required	A Threads username, @handle, or full profile URL, e.g. instagram, @instagram, or https://www.threads.com/@instagram.

{
  "username": "zuck"
}

Response fields

Field	Contents
user_id	Threads' own numeric ID for the account, as a string
username	The account's Threads username
requested_username	The value this run asked for, echoed back
full_name	The account's display name
biography	The account's bio, plain text
follower_count	Followers, read at the moment of the request
is_verified	Whether the account carries Threads' verification mark
is_private	Whether the account is private
profile_pic_url	The account's avatar
hd_profile_pic_versions	The avatar at larger sizes, each an object with url, width and height
bio_links	Links in the account's bio
profile_tags	The topic tags Threads shows on the profile, republished whole
raw	The complete profile record exactly as Threads' own internal API returns it

{
  "user_id": "63055343223",
  "username": "zuck",
  "full_name": "Mark Zuckerberg",
  "biography": "Mostly superintelligence and MMA takes",
  "follower_count": 5723633,
  "is_verified": true,
  "is_private": false
}

The raw field

Threads publishes no documented schema for this data — the fields above are the ones consistently present and worth a column of their own, pulled from a record that, measured live, carries several dozen fields, some of them internal (gating, transparency_label, podcast metadata that is null on non-podcast accounts). Everything not listed in the table above is still in the row, inside raw, exactly as Threads returned it. A field missing from the table today is not missing from the data.

Behaviour on an account that cannot be resolved

A username, handle, or URL that does not resolve to a real account finishes the run with an empty dataset rather than failing it — this covers both a deleted account and one that was never a Threads account at all. The distinction is not exposed, since Threads itself does not expose it consistently: what Threads answers for "never existed" and for "deleted" is not the same response every time, and this Actor treats both as one outcome rather than guessing between them.

Frequently asked questions

Why is follower_count slightly different if I run this twice? It is a live counter, read at request time. Two runs minutes apart on a fast-growing account will disagree, and that is drift rather than a fault.

What is the difference between biography and the bio shown in raw? biography is the plain-text bio. Threads also carries a richer, structured version of the same text internally (with mention and link fragments broken out); that structured form is available in raw for a caller who needs the fragments rather than the flat string.

Why is profile_tags sometimes null? Not every account has topic tags attached. null means the account carries none, not that the field failed to load.

Can I look up several accounts in one run? Each run takes one username. For a list, run the Actor once per username, or drive it from a task with different input each time.

Related

Threads Posts Scraper exports an account's public posts by user_id — the exact value this Actor returns. Threads Post Scraper fetches one post by its link. Threads Search Scraper finds public posts by keyword.