🧵✨ Threads User Followers Scraper

Threads User Followers Scraper — Handles, Names, Follower Count

Threads User Followers Scraper turns any Threads profile into a structured list of the accounts that follow it: username, full_name, follower_count, is_verified, is_private, profile_url and the numeric user_id, plus the follower's relationship to your own account. Sixteen typed JSON keys on every row, pushed into the dataset live as each follower is found, exportable to CSV, Excel or JSON. Paste one profile or a hundred, add your session cookie, press Start.

⚠️ Read the session-cookie requirement below before your first run. Threads serves follower lists only to a logged-in session, so this Actor needs your own sessionid cookie. Without it the run logs an error and exits with an empty dataset — it does not return followers.

What is Threads User Followers Scraper?

Threads User Followers Scraper is an Apify Actor that reads Threads' own followers GraphQL query for each profile you give it and flattens every follower into one typed dataset row. One run can cover many seed profiles, and each row is stamped with target_username so you always know which account the follower belongs to.

A Threads login is required — not an Apify-side account, but your own browser session, supplied as the sessionId input. Threads returns no follower list to an anonymous request, which is a Meta platform behaviour rather than an Actor limitation. Everything returned is data your logged-in account is already permitted to see.

It is built for influencer marketers qualifying audiences, community and growth managers mapping overlap between accounts, researchers studying follower graphs, and developers piping social identity data into their own dashboards or AI pipelines.

What Threads follower data is publicly available to scrape?

A Threads profile page — handle, display name, bio, avatar and public posts — is readable by a signed-out visitor on the web. The follower list is not: Meta puts the followers tab behind a logged-in session, which is exactly why this Actor asks for one.

Data Category	Visible signed out	Requires a logged-in session
Profile handle, display name, avatar, follower count	✅ Public	—
Public posts and replies	✅ Public	—
Follower list of a public account	❌	Followers tab is login-walled — this is what the Actor reads
Following list (who an account follows)	❌	Login-walled, and not returned by this Actor at all
Follower or following list of a private account	❌	Visible only to accounts that profile has approved
Your relationship to a follower (following, followed_by, outgoing_request)	❌	Derived from your own session's viewpoint
Follower's bio, posts or engagement history	❌	Not in the followers payload — use a profile or posts Actor
Email addresses, phone numbers, direct messages	❌	Never returned

Threads User Followers Scraper only returns publicly visible data — what any logged-in visitor sees on the followers tab. Nothing behind a follow approval, and nothing from a private account's list.

⚠️ You must supply your own Threads session cookie

This is the one prerequisite, and it belongs at the top rather than buried in the input table.

The Actor loads https://www.threads.com/@<username>, reads the live tokens Meta embeds there — the APP_ID, a fresh CSRF token, the profile's numeric id, and the doc_id of the BarcelonaFriendshipsFollowersTabQuery persisted query — then posts that query to https://www.threads.com/graphql/query. Every one of those steps goes out with your cookie attached. On a logged-out response the followers query is not answerable, so there is nothing to read.

How to supply it:

1. Log in to Threads or Instagram in your browser (the two share the same session cookie)
2. Open DevTools (F12) → Application → Cookies → threads.com or instagram.com
3. Copy the value of the sessionid cookie into the sessionId input

Four behaviours worth knowing before you run it:

• No sessionId: the run logs Input 'sessionId' is required (session cookie). Exiting. and finishes with zero rows. No dataset row explains it — check the log.
• Expired or flagged cookie: the Actor can no longer read a CSRF token from the profile page, logs session may have expired. Refresh your cookie and try again., and moves on to the next profile. Refresh the cookie from a logged-in browser and re-run.
• The field is not stored as a secret. The input schema does not mark sessionId with isSecret, so the value is visible in the Actor's input and run history like any other input. Treat it as a password: use an account you are willing to expose, and rotate the cookie by logging out when you are done.
• Replaying a session carries account risk. Any account whose session cookie is driven by automation from cloud IP addresses carries a real risk of being challenged, rate-limited or locked by Meta. That is inherent to session replay, not specific to this Actor. Do not use an account you cannot afford to lose.

What data can I extract with Threads User Followers Scraper?

Every follower row carries the same 16 keys: where it came from, who the follower is, how big their own audience is, what state their account is in, and how they relate to the account you are logged in as.

Field Name	Description
source	Constant "threads" — the platform the row came from
target_username	The seed profile whose follower list this row belongs to
user_id	The follower's numeric Threads/Instagram id, as a string
pk	The follower's primary key from the same payload, as a string — normally identical to user_id
username	The follower's handle, without the @
full_name	The follower's display name, "" when they have not set one
is_verified	true when the follower's account is verified
is_private	true when the follower's account is private — read from Threads' text_post_app_is_private
profile_pic_url	Direct URL to the follower's avatar image
follower_count	How many followers the follower themself has, 0 when Threads omits it
following	true when your logged-in account follows this follower
followed_by	true when this follower follows your logged-in account back
outgoing_request	true when your account has a pending follow request to this follower
has_onboarded_to_text_post_app	true when the account has actually set up Threads, not just Instagram
__typename	Threads' own GraphQL type label, "XDTUserDict"
profile_url	Canonical https://www.threads.net/@handle link, "" when the handle is missing

All 16 keys are written on every row. Nothing is omitted conditionally — missing values fall back to "", 0 or false, so a follower_count of 0 means "Threads did not send one" as well as "genuinely zero". Field names are snake_case in the output while the input parameters are camelCase; that mismatch is deliberate, because the output keys mirror Threads' own payload names.

Follower identity fields

username, full_name, user_id, pk and profile_url identify the person. user_id and pk come from two separate keys in the upstream node (id and pk) and are kept separate rather than merged, so a future divergence in Meta's payload does not silently change which id you are storing. profile_url is built on threads.net even though the Actor scrapes threads.com — both hostnames resolve to the same profile, so links stay clickable either way. profile_pic_url is a CDN URL with a signature that expires; download the image if you need to keep it. target_username is what makes a multi-profile run usable — group or pivot on it and you have one follower table per seed account.

Counts, flags and relationship fields

follower_count is the follower's own audience size, which is the field that separates a high-reach follower from a throwaway account. is_verified and is_private describe the account's state; has_onboarded_to_text_post_app is the one flag with no equivalent on other platforms — a linked Instagram account can appear in a Threads follower list without having activated Threads at all, and this flag tells you which.

following, followed_by and outgoing_request are read from Threads' friendship_status block, which is always relative to the session you supplied. They describe the relationship between your own account and the follower, not between the follower and the seed profile. Run the same profile with a different sessionId and those three fields legitimately change while the other thirteen do not.

🤖 Add-on: Need additional Threads data?

A follower list is usually the start of a workflow rather than the end of it. Threads User Posts Scraper By Keyword & Date Filter takes a username from these rows and pulls what that account actually posts, which is how you tell an active follower from a dormant one. Because Threads accounts are Instagram-linked, Instagram Profile Scraper turns the same handle into bio and profile detail, and Instagram Following Change Tracker watches how a follow graph shifts between runs.

Why not build this yourself?

You can — the request chain is documented above and it is not secret. What makes it a maintenance job rather than a script is what sits inside each step.

Meta does publish a Threads API, but it is built around your own account: posting, reading your own posts, and your own insights. It publishes no third-party follower-list endpoint, so there is no supported route to another account's followers. Verify the current scope against Meta's published Threads API documentation before assuming otherwise — no rate figures are quoted here because they are Meta's to state, not ours.

That leaves the web surface, and three moving parts:

The persisted query id. The followers query is a Relay persisted query addressed by a numeric doc_id that changes with every Threads front-end build. This Actor discovers it at runtime by fetching the profile page, enumerating its static.cdninstagram.com JavaScript bundles, and regex-matching BarcelonaFriendshipsFollowersTabQuery inside them. Hard-code the id and your scraper dies at the next deploy.

The Relay provider variables. The same query declares a large set of __relay_internal__pv__*relayprovider flags, and if a single one the persisted query references is missing from your POST variables, Meta answers HTTP 200 with {"errors":[...],"data":null} — a success status code carrying nothing. This Actor scrapes the live flag names out of those same bundles and merges them with a known-good fallback list of 50 names, so it always sends a valid superset.

The IP model. Meta soft-blocks the followers query on datacenter addresses by returning HTTP 200 with an empty edges array rather than an error, which is indistinguishable from "this account has no followers" unless you handle it deliberately. Getting that right means a proxy ladder, residential egress for the query itself, and treating an empty first page as a block signal — all of which is described below.

How to use Threads User Followers Scraper

Threads User Followers Scraper runs on Apify. Start it from the Apify Console or call it through the Apify API.

1. Open Threads User Followers Scraper on Apify and click Try for free
2. Paste your sessionid cookie into Your logged-in session — one of the two required inputs
3. Add one or more entries to Profiles to look up — the other required input. @zuck, zuck, or https://www.threads.com/@zuck all work
4. Set How many people per profile? (maxFollowers) to cap rows per seed profile
5. Leave Network options alone unless you have your own Apify Proxy preference, then click Start
6. Download the dataset as JSON, CSV or Excel, or read it through the Apify API

A run missing either required input stops before it fetches anything, and the two cases log different errors. Without sessionId the log reads Input 'sessionId' is required (session cookie). Exiting. Without a usable entry in urls it reads Input 'urls' must contain at least one Threads @username or profile URL. Both finish with an empty dataset and no explanatory row, so read the log rather than the Output tab when a run comes back empty. The Console blocks both cases before the run starts; they only bite callers who build the input JSON themselves.

How to scale to bulk follower extraction

urls is a list, so bulk is the normal mode: add as many profiles as you like and the Actor works through them in order, resolving fresh tokens for each one and pushing rows as it goes. maxFollowers applies per profile, not per run, so ten profiles at maxFollowers: 50 is a 500-row target rather than a 50-row one.

Four entry forms are accepted: a bare handle (zuck), an @handle, a threads.com/@handle or threads.net/@handle URL — including deep links, which are trimmed back to the handle — and {"url": "..."} objects, so output from another tool usually feeds in unchanged. One trap: anything that is not recognisably a Threads URL is not rejected, it is treated as a literal handle. Paste an Instagram or LinkedIn URL and the Actor will try to open a profile by that name, fail to resolve tokens, log Couldn't open @... after several tries — skipping this profile, and move on.

What can you do with Threads follower data?

• 📣 An influencer marketer vetting a creator collaboration sorts a creator's followers by follower_count and filters on is_verified to see how much of that audience is itself influential, rather than trusting a headline follower number.
• 🔁 A community manager measuring audience overlap runs three competitor accounts in one job and counts how often the same user_id appears across different target_username values — the intersection is the audience all three are fighting over.
• 🤝 A growth lead planning outreach filters on followed_by to find which of a target account's followers already follow them back, and on outgoing_request to avoid re-requesting accounts that have a pending request.
• 🧵 A social researcher studying platform adoption filters on has_onboarded_to_text_post_app to separate genuine Threads users from linked Instagram accounts that never activated, then uses is_private to see how much of the graph is closed off.
• 🤖 An AI engineer building an audience-research agent indexes username, full_name, follower_count and is_verified per target_username into a vector store, so the agent can answer "who follows this account and which of them have real reach" against a live pull instead of a stale spreadsheet export.

Every one of these is callable from an agent framework over the Apify API, since the Actor is a standard HTTP-triggered run.

How does Threads User Followers Scraper handle rate limits and blocking?

No browser is launched and no CAPTCHA solving is involved — none is claimed. Requests go out over plain HTTP with your session cookies and a full desktop Chrome header set, which is what the GraphQL endpoint expects.

Egress runs on a proxy ladder. Token resolution starts on a direct connection; if that does not yield a complete token set, the Actor escalates to an Apify datacenter proxy, then takes up to three fresh Apify Residential IPs. Once residential succeeds it stays sticky for the rest of the run. The followers query itself is different: because Meta soft-blocks it on datacenter addresses, the Actor forces that POST through residential from the very first page even when tokens resolved directly. Budget residential proxy usage accordingly.

Two failure signatures are handled explicitly. A GraphQL execution error — HTTP 200 with data: null and an errors array — is logged and treated as a failed page, not as an empty list. An HTTP 200 carrying an empty followers page while nothing has been collected yet is treated as an IP soft-block: the Actor rotates to a fresh residential IP, waits three seconds and retries, up to four times, before giving up on that profile.

A profile whose tokens never resolve is skipped with a log line and the run continues with the rest of your list. Rows already collected are always kept.

⬇️ Input

Two inputs are required: urls and sessionId. The other two have defaults.

Parameter	Required	Type	Description	Example Value
urls	✅ Yes	array	Threads profile links or plain usernames, one entry per line. A bare handle, an @handle, a threads.com/@handle or threads.net/@handle URL, and {"url": "..."} objects are all accepted. Prefilled with ["zuck"].	["@zuck", "https://www.threads.com/@mosseri"]
sessionId	✅ Yes	string	Your sessionid cookie from a logged-in Threads or Instagram browser session. The followers tab is login-walled, so nothing can be fetched without it. Default "".	"73956966771%3AqR7tVbNm2XyZaP%3A17"
maxFollowers	No	integer	Cap on unique follower rows collected per profile in urls, not per run. Minimum 1, maximum 100000. Default 20.	50
proxyConfiguration	No	object	Apify Proxy settings, used as the base configuration for the Actor's own proxy ladder. Prefilled with {"useApifyProxy": true}.	{"useApifyProxy": true}

Four honest notes on how these actually behave:

• maxFollowers has a different default in code than in the schema. The schema default is 20, which is what the Console prefills. The code reads max(1, int(actor_input.get("maxFollowers") or 200)) — so an API caller who omits the field, sends null, or sends 0 gets a target of 200, not 20. The max(1, ...) guard clamps a negative value up to 1. The 100000 ceiling is enforced by the platform's schema validation, not by the code.
• The pagination ceiling is the real limit, not maxFollowers. The followers query is sent with first: 50 and no pagination cursor — the same first page is requested each round. Rows are deduplicated, so a repeated page contributes nothing new, and the run ends when 10 consecutive rounds add no new unique follower. In practice that puts the per-profile yield at roughly the size of the first page Threads returns, whatever you set maxFollowers to. Set it low deliberately for a sample; setting it to 100000 will not deepen the pull. This is the Actor's own limit, not a documented Meta cap.
• proxyConfiguration is honoured only as a base. Whatever you pass is merged, but the Actor then overwrites useApifyProxy to true and sets apifyProxyGroups itself — datacenter on the second rung, residential on the third and for the followers query. A custom proxy group selection does not survive that merge, and turning Apify Proxy off does not produce a proxy-free run beyond the very first direct attempt.
• sessionid is accepted as an alias. The code reads sessionId first and falls back to a lower-case sessionid key, so an API caller who uses the cookie's own spelling still works. The Console only shows sessionId.

Example input

{
  "urls": [
    "@zuck",
    "https://www.threads.com/@mosseri",
    "natgeo"
  ],
  "sessionId": "73956966771%3AqR7tVbNm2XyZaP%3A17%3AAYd8kQpLxWm",
  "maxFollowers": 50,
  "proxyConfiguration": {
    "useApifyProxy": true
  }
}

⬆️ Output

Typed, normalized JSON with a consistent shape across runs — 16 keys on every row, always present. Rows are pushed live as each follower is parsed, so the dataset fills while the run is still going, profile by profile. Export as JSON, CSV or Excel, or read the dataset through the Apify API. The Console's default table view shows eight of the sixteen columns — target_username, username, full_name, follower_count, is_verified, is_private, profile_url, user_id — but the other eight are in every exported record. Export the JSON, or read the dataset through the API, to see all of them.

Charging and row types. The dataset contains follower rows and nothing else. Each one is charged as a single row_result event, and there are no header rows, no diagnostic rows and no accounting rows — so there is no filter expression to apply and nothing to skip in your loop. The flip side is that failures leave no trace in the dataset: a missing cookie, an unresolvable profile, or a soft-blocked query produces log lines and fewer rows, never an explanatory record. Read the run log when a run returns less than you expected.

Deduplication is per profile, not per run. Within one target_username, followers are deduplicated on pk, falling back to user_id and then to @username. Across profiles they are not: an account that follows two of your seed profiles is written twice, once under each target_username. That is what makes the overlap analysis above possible — deduplicate on user_id yourself if you want a flat unique list.

Example output

A verified follower, from a run seeded with @zuck:

{
  "source": "threads",
  "target_username": "zuck",
  "user_id": "73956966771",
  "pk": "73956966771",
  "username": "mosseri",
  "full_name": "Adam Mosseri",
  "is_verified": true,
  "is_private": false,
  "profile_pic_url": "https://scontent-lhr8-1.cdninstagram.com/v/t51.2885-19/357614920_18374_n.jpg",
  "follower_count": 1284037,
  "following": true,
  "followed_by": false,
  "outgoing_request": false,
  "has_onboarded_to_text_post_app": true,
  "__typename": "XDTUserDict",
  "profile_url": "https://www.threads.net/@mosseri"
}

A private follower with no display name, from the same run — note that nothing is omitted, the empty values are typed fallbacks:

{
  "source": "threads",
  "target_username": "zuck",
  "user_id": "68412907553",
  "pk": "68412907553",
  "username": "k.rendall_",
  "full_name": "",
  "is_verified": false,
  "is_private": true,
  "profile_pic_url": "https://scontent-lhr8-2.cdninstagram.com/v/t51.2885-19/582885718_17844_n.jpg",
  "follower_count": 0,
  "following": false,
  "followed_by": false,
  "outgoing_request": false,
  "has_onboarded_to_text_post_app": false,
  "__typename": "XDTUserDict",
  "profile_url": "https://www.threads.net/@k.rendall_"
}

How does it work?

Threads builds its followers tab from a Relay persisted GraphQL query, not from rendered HTML. For each profile in your list, the Actor loads https://www.threads.com/@<handle> with your session cookie attached and reads the live values Meta embeds in that page: the APP_ID, a CSRF token, the profile's numeric id, and the JavaScript bundle URLs. It fetches those bundles concurrently, pulls the current doc_id for the followers query out of them, and harvests the Relay provider flag names at the same time so the POST variables are always a valid superset.

It then posts that query through an Apify Residential IP, refreshing the CSRF token before each round, pausing roughly a third of a second between rounds, and pushing every new unique follower straight into the dataset. Because it reads structured JSON rather than markup, a Threads front-end redesign does not change your field names — and only data your logged-in account is already permitted to see is ever returned.

Integrations

Threads User Followers Scraper is an Apify Actor, so it works with anything that can call the Apify API or consume a dataset.

Calling Threads User Followers Scraper from Python

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run = client.actor("<YOUR_USERNAME>/threads-user-followers-scraper").call(run_input={
    "urls": ["@zuck", "https://www.threads.com/@mosseri"],
    "sessionId": "<YOUR_THREADS_SESSIONID>",
    "maxFollowers": 50,
    "proxyConfiguration": {"useApifyProxy": True},
})

for row in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(row["target_username"], row["username"], row["follower_count"], row["is_verified"])

Works in Go, Ruby, Node.js, cURL — any language that can make an HTTP request. Every row has the same 16 keys, so there is nothing to branch on and no metadata rows to skip.

No-code tools (n8n, Make, LangChain)

In n8n, use the Apify node — or an HTTP Request node pointed at the Apify run endpoint with your token — and pass the same JSON input shown above; a Filter node on follower_count or is_verified trims the list before it reaches your CRM step. In Make, the Apify module supports run-and-wait, so a weekly competitor-audience pull can feed a Google Sheets or Airtable step directly. In LangChain, wrap the run endpoint as a tool and hand the rows straight to the model, since they are already flat typed JSON. Apify schedules and webhooks cover recurrence and completion triggers, so a recurring follower snapshot needs no code of your own.

Is it legal to scrape Threads followers?

Scraping publicly accessible content is broadly treated as permissible where no access control is circumvented, but that framing does not carry this output on its own.

This output is personal data, and a follower list is one of the clearer cases. username, full_name, user_id, pk, profile_url and profile_pic_url identify real individuals; follower_count, is_verified, is_private and has_onboarded_to_text_post_app are attributes of those individuals; following, followed_by and outgoing_request describe their relationship to your account; and target_username adds the inferred fact that each of them follows a particular account. Collecting one public profile and collecting a whole follower graph are not the same processing activity — the second builds a relationship dataset about thousands of people who never interacted with you, which is a materially more sensitive operation and is treated as such by regulators.

Under GDPR, UK GDPR and CCPA/CPRA, plan for the whole lifecycle before you run it:

• Lawful basis. If you rely on legitimate interests, document a balancing test that names your purpose, why the follower graph is necessary for it, and why the impact on those individuals is proportionate. Write it down before collection, not after a complaint.
• Data minimisation. Keep only the columns your purpose needs. Drop profile_pic_url first — a stored facial image is the highest-risk field here and its URL expires anyway — then full_name, then the relationship flags if you are not using them, then pk, __typename and source, which are duplicative or constant.
• Retention. Set a deletion date at ingestion. A follower list is a snapshot of a moment and goes stale on its own.
• Transparency and subject rights. Your privacy notice must cover data collected from third-party sources, and you need a workable process for access, deletion and objection requests keyed on user_id or username.

Only followers your logged-in account is permitted to see are returned; private accounts' follower lists remain inaccessible. Separately, you are supplying your own session cookie, which is governed by Meta's terms of service — read them and decide for yourself. Consult legal counsel if your use case involves bulk storage of personal data, profiling of identified individuals, or transferring these rows outside your jurisdiction.

❓ Frequently asked questions

What Threads follower fields does Threads User Followers Scraper return?

The five most used are username, full_name, follower_count, is_verified and profile_url. Every row carries 16 keys in total, including target_username for the seed profile and the three friendship_status flags — see the data fields table above for all of them.

Does Threads User Followers Scraper require a Threads account or login?

Yes — your own session, supplied as the sessionId input. Threads serves the followers tab only to a logged-in session, so this is unavoidable rather than a design choice. Both required inputs are enforced by the schema, and without sessionId the run logs an error and exits with zero rows. Note that the field is not marked as a secret in the schema, so the cookie value appears in the run's input record; use an account you are comfortable exposing, and be aware that automating a session cookie from cloud IPs risks a Meta challenge or lock on that account.

How many followers can I extract per profile in one run?

Fewer than maxFollowers suggests, and this is the Actor's most important limitation. The followers query is sent with first: 50 and no pagination cursor, so every round asks Threads for the same first page. Duplicates are dropped, and the run stops after 10 consecutive rounds that add nothing new — which means the practical per-profile yield is about the size of one page, regardless of whether you set maxFollowers to 20 or to 100000. Bulk depth therefore comes from the number of profiles in urls, not from raising the cap. There is no cursor-based deep pagination in this build.

What happens if a seed profile is private, does not exist, or has no followers?

The run continues in all three cases — it does not crash, and it does not write an error row.

• Profile does not exist, or the handle is not resolvable: token extraction fails, the log reads Couldn't open @<handle> after several tries — skipping this profile, and the Actor moves to the next entry in urls.
• Profile is private and your account is not an approved follower: the followers query answers with an empty page. The Actor cannot tell that apart from an IP soft-block, so it rotates to a fresh residential IP and retries up to four times, then finishes that profile with 0 follower row(s) saved.
• Profile genuinely has no followers: identical behaviour to the private case — four rotations, then zero rows for that profile.

In code, the signal is simply the absence of rows for that target_username. Because no diagnostic row is written, check the run log to tell these three apart.

Can I scrape multiple Threads profiles at once?

Yes. urls is a list and the Actor works through it in order, resolving fresh tokens per profile and tagging every row with target_username. maxFollowers applies per profile, so ten profiles at 50 each is a 500-row target. Bare handles, @handles, threads.com/threads.net URLs and {"url": "..."} objects are all accepted; anything unrecognisable is treated as a handle and then skipped when it fails to open.

Can it return who a profile follows instead of who follows them?

No. This Actor sends only BarcelonaFriendshipsFollowersTabQuery — the followers direction — and there is no input to reverse it. The following field in the output is not the seed profile's following list; it is a flag saying whether your logged-in account follows that particular follower. For the following direction you need a separate following-list Actor.

Does Threads User Followers Scraper work with Claude, ChatGPT and other AI agent tools?

Yes. It is callable as a standard HTTP-triggered run through the Apify API, so LangChain, CrewAI, n8n or a hand-written tool definition can invoke it and receive typed JSON with no parsing step. Because the dataset contains only follower rows, an agent can consume the output without any filtering logic.

How does Threads User Followers Scraper compare to other Threads follower scrapers?

Checked on the Apify Store on 25 July 2026, the category is small and the differences are concrete. igview-owner/threads-user-followers-scraper has the longest README of the three: it takes a single username plus max_followers, documents a 1–1000 extraction range, advertises five dataset views including a summary-statistics record, and states in its FAQ that no login credentials are required. apibox/threads-user-followers-scraper documents a minimal username / num input and an output example of six fields — id, profile_pic_url, username, full_name, follower_count, is_verified — with monthly flat-price billing on its listing. scrapelabsapi/threads-user-following-scraper covers the opposite direction, who an account follows, and its README was not reachable when checked, so nothing is claimed about it here.

What this Actor documents that those listings do not: bulk urls input with URL normalisation, the sessionId requirement stated as a requirement, the three friendship_status relationship flags and has_onboarded_to_text_post_app, target_username on every row for multi-profile runs, and the pagination ceiling stated plainly rather than implied by a maximum. Neither of the reachable competitor listings documents a session-cookie input; that is an observation about their READMEs, not a statement that they do not use one.

Does Threads User Followers Scraper return data in a format LLMs can use directly?

Yes. Typed, normalized JSON with the same 16 field names on every row across runs. No HTML parsing, no selectors, no conditional keys. Pass a row straight into an LLM context window, index it into a vector store, or hand it to an agent tool.

What happens when Threads changes its layout or anti-bot system?

The scraper is maintained, and its design already assumes Threads changes constantly: the persisted-query doc_id and the Relay provider flag names are discovered from the live JavaScript bundles on every run rather than hard-coded, and the data itself comes from a JSON GraphQL response rather than rendered markup. A front-end redesign therefore generally does not affect your field names or types at all. The failure you are most likely to hit is not a layout change but an expired sessionId — that one is on your side to refresh.

Can I use Threads User Followers Scraper without managing proxies?

Yes. The ladder is automatic — direct, then Apify datacenter, then up to three fresh Apify Residential IPs, sticky once residential works — and the followers query itself is forced onto residential regardless, because Meta withholds follower edges from datacenter addresses. You never create a proxy account or rotate an IP. There is no CAPTCHA solving and no browser to run. The one thing you manage yourself is the session cookie, which expires and needs refreshing.

Which Threads follower fields work best for AI training data and RAG indexing?

For RAG indexing, full_name and username are the only free-text fields, so a useful chunk is a compact record joining them with target_username and profile_url — the retrievable unit here is "this identifiable person follows this account", not a document. For training data or scoring, follower_count, is_verified, is_private and has_onboarded_to_text_post_app are the most structurally consistent fields: an integer and three booleans, present on every row. All values return as typed primitives, so no normalisation pass is needed. Remember that full_name is often "" and follower_count falls back to 0, and that indexing this output into a vector store means storing personal data — apply the minimisation notes above before you embed it.

🔗 Related scrapers

Scraper Name	What it extracts
Threads User Posts Scraper By Keyword & Date Filter	Posts from a Threads profile, filtered by keyword and date
Instagram Profile Scraper	Bio, follower counts and profile metadata for a handle
Instagram Following Change Tracker	Follow and unfollow changes on an account between runs
Instagram Related Person Scraper	Accounts Instagram suggests as related to a profile
Instagram Comment Leads Scraper	Commenter identity and comment text under a post
Twitter (X) Posts Scraper	Public posts and engagement metrics from X

💬 Your feedback

Found a bug, or need a field that is in the Threads followers payload but not in the output? Open an issue on the Actor's Issues tab. Reports that include the exact input JSON and the seed handle you ran are the fastest to reproduce and fix — and if cursor-based deep pagination is what you need, say so there, because demand is how it gets prioritised.