Threads Followers & Following Scraper

By scraping_solutions. Extract public Threads follower or following profiles, with validated inputs, deduplication, incremental results, budget protection and resumable progress.

No Threads login, cookies, additional API key or separate service subscription is required. Enter the accounts you want to analyze and run the Actor on Apify.

Quick start

{
  "usernames": ["neeturaj2525"],
  "type": "followers",
  "maxResultsPerUser": 20
}

1. Enter public usernames, @usernames, or Threads profile URLs.
2. Choose followers or following. Each run extracts one relationship.
3. Set a result maximum and, on Apify, the maximum run charge and timeout.
4. Run and inspect the dataset and the key-value store's OUTPUT record. Export results through Apify as JSON, CSV or Excel.

The result maximum is not a guarantee of availability. A response without a pagination cursor ends that relation even when fewer results are available than requested.

Input

Field	Type	Default	Meaning
usernames	String array	Required	Public Threads usernames or profile URLs; duplicate sources are processed once.
type	String	followers	followers or following. One relationship per run.
maxResultsPerUser	Integer, minimum 0	100	Maximum saved profiles per source account for the selected relationship. 0 means all accessible, subject to quota and budget.

Whitespace at the ends and a leading @ are removed. Profile URLs on threads.com or threads.net are normalized to lowercase usernames. Internal spaces, emails, empty names, invalid characters and non-profile URLs are rejected before provider calls. Valid entries in a mixed list continue; rejected entry indexes and reasons appear in warnings and OUTPUT.rejectedInputs. If none are valid, the run reports INVALID_INPUT, exits nonzero and makes no provider requests.

Usernames accept 1-30 ASCII letters, numbers, underscores or dots; the first character cannot be a dot. Unsupported objects and non-string array entries are rejected. Limits must be integers, not strings, booleans or decimal values.

One relationship per run. A limit of 100 means up to 100 followers OR up to 100 following per account. To extract the other relationship, start a separate run with fresh storage. Old inputs containing type: "both" or maxRequests are rejected before provider calls; select a supported type and remove the obsolete field.

Free plan limits

The following limits apply to Apify Free accounts. They do not apply to paid Apify accounts.

Apify Free execution channel	Accounts per run	Per-run configured cap	Daily reserved-result cap	Runs per UTC day
API / MCP / automation	First valid account only	1,300	1,000	5
Apify Console / Web	First valid account only	1,750	1,750	15

The smaller remaining allowance wins: API/MCP can never actually deliver more than 1,000 per day, despite the 1,300 per-run setting. A result limit of 0 does not bypass Free limits. Paid Apify accounts have no additional Free-plan cap.

API, MCP, CLI, Actor calls, scheduled jobs, webhooks and unknown origins share the API bucket. Web has its own bucket. One quota reservation is reused when the same run resumes. Different runs may use different source accounts, but share the same customer/day/channel allowance.

Quota is reserved before extraction and is not refunded after failures, early ends or cancellations. Reservations are NOT charges: only saved unique result rows generate result events. An Apify Free account does not mean that using the Actor is free of charge.

Daily exhaustion reports FREE_API_DAILY_LIMIT_REACHED or FREE_WEB_DAILY_LIMIT_REACHED before extraction. If your Apify plan or remaining allowance cannot be verified, the run stops without fetching profiles rather than silently bypassing the limit.

Output fields

One dataset row is one found profile. Audit records and summaries are never mixed into customer results.

Field	Meaning
sourceUsername	Normalized source account.
relation	follower or following.
userId	Profile identifier, preserved as a string.
username	Returned username, when supplied.
profileUrl	Threads profile link derived from a valid returned username: https://www.threads.com/@username.
fullName	Display name, when available.
followersCount	Follower count of the found profile, when available as a non-negative integer. A real zero is preserved.
profilePicUrl	Profile picture URL, when available.
isVerified	Verification status, when available as a boolean.
isPrivate	Privacy status of the found profile, when available as a boolean.
scrapedAt	Extraction time in UTC, ISO 8601.

Missing values are omitted, not fabricated. Records without a usable ID are skipped; if an entire non-empty response lacks IDs, it is a provider-format error.

followersCount describes each downloaded profile, not the source account or the number of rows extracted. A missing or invalid count is omitted, never replaced with zero. profileUrl is omitted if no valid username is available. These fields use the existing page response, with no extra requests or enrichment charge. Existing dataset rows are not retroactively updated.

Illustrative output with synthetic values:

{
  "sourceUsername": "neeturaj2525",
  "relation": "follower",
  "userId": "1234567890",
  "username": "example_profile",
  "profileUrl": "https://www.threads.com/@example_profile",
  "fullName": "Example Profile",
  "followersCount": 1250,
  "profilePicUrl": "https://example.com/avatar.jpg",
  "isVerified": false,
  "isPrivate": false,
  "scrapedAt": "2026-09-27T09:00:00Z"
}

Pricing: result-only pay-per-event

Prices verified on September 28, 2026, against the active Apify monetization configuration effective September 27, 2026, at 23:40 UTC. See the Actor's Pricing tab for the current price applicable to your Apify account. All prices are in USD.

Customer plan	Price per 1,000 unique saved results
Free / no discount	$1.00
Starter / Bronze discount	$0.95
Scale / Silver discount	$0.90
Business / Gold discount	$0.85
Platinum discount	$0.85
Diamond discount	$0.85

• The only billing event is Result (apify-default-dataset-item), one event per unique saved profile within each source account and relationship.
• No start event, page event, retry fee, duplicate charge or audit-record fee.
• A profile repeated within the same source account and relation is removed before any write or charge. The same profile in two different source audiences or relations represents two distinct records.
• Results are capped before saving. The SDK's affordable count is checked before fetching and writing. An insufficient full-request budget does not prevent a smaller affordable extraction.
• Result events are generated by the default dataset write. The Actor does not manually charge a second event.
• The result count is checked against SDK receipts and event counters. In PPE runs, sdk_result_events_charged == results_saved is required; mismatches stop processing for reconciliation and are never relabeled successful or retried as another write.

No separate data-service subscription is needed. Set a maximum run charge in Apify and start with a small result limit. A Free-plan quota reservation is not an extra billable event.

Reliability and stop rules

• Sequential provider requests, with streamed page results.
• HTTP 429, 5xx, transport failures and empty responses: at most two retries after the first attempt, with 3- and 9-second waits. A valid larger Retry-After is honored up to 300 seconds. Mixed failure types share the same three-attempt total.
• Persistent 429/5xx ends that source account with a provider error; other accounts can continue.
• Three empty responses stop the entire run with PROVIDER_ERROR, retaining any results already delivered. An empty page's new cursor is not followed during retries.
• HTTP 401/403 stops all accounts with a service-access error. Contact Actor support with your run ID; you do not need to supply an additional API key.
• Missing/private accounts generate a warning and do not prevent later accounts from being processed.
• A repeated or cyclic cursor stops pagination and sets stop_repeated_cursor. Already fulfilling the requested result limit is still a normal SUCCESS.
• A missing next cursor on a non-empty page is a natural end, not a partial failure.

Audit / OUTPUT status	Meaning
SUCCESS	Requested maximum reached, or accessible pagination ended naturally. Fewer followers than requested is not by itself an error.
PARTIAL	Some results retained but work could not complete because of budget, timeout, provider error or unavailable targets. Always includes partial_reason.
NO_RESULTS	No saved results without a classified failure; repeated empty provider responses are NOT classified this way.
UNAVAILABLE	Requested targets were missing/private/restricted and no results were saved.
INVALID_INPUT	No valid source or invalid configuration; no provider work.
PROVIDER_ERROR	Provider/authentication failure; can retain results saved earlier.
PROCESSING_FAILED	Processing/configuration/storage failure or interruption.
LIMIT_REACHED	Internal test request cap reached; progress is retained. This cap is not a customer input.
FREE_API_DAILY_LIMIT_REACHED / FREE_WEB_DAILY_LIMIT_REACHED	Free daily quota exhausted before provider work.
NO_BUDGET	Cannot afford one more result and nothing was delivered.

These are business/audit states. Apify's platform status is separate; for example, a handled partial result may have platform status SUCCEEDED. Invalid input, provider errors and processing failures exit nonzero. The audit records the platform status actually known at its snapshot, not a guessed future status.

Summary and private audit

OUTPUT and the final log contain per-account/relation delivery counts, rejected entry indexes/reasons, duplicates removed, request usage, account errors, stop causes and SDK result event counts.

Each orderly run attempts one final record in a dedicated, owner-restricted audit dataset. It contains counts, statuses, sanitized error details, Apify run context and input.usernames: the valid, normalized, deduplicated source accounts requested in the input. These are recorded before Free-plan restrictions reduce the list; they do not imply that every requested account was processed. Check OUTPUT.accounts for processed-account results. Input that fails configuration validation may have an empty audited username list.

In the audit, metrics.results_delivered is the total number of confirmed saved results across all processed accounts. It equals metrics.results_saved (retained for compatibility) and billing.results_delivered. metrics.items_received counts profiles received from the service before deduplication and limits; it is not the delivered count. metrics.sdk_result_events_charged separately records reported result events. Audit metrics contain counts, not downloaded profile rows.

Downloaded follower/following profiles, social-profile IDs, cookies, cursors, biographies, credentials and rejected raw input are not copied into the audit. Apify run/user/build/dataset IDs are included; they are not social-profile IDs. Existing audit records are not backfilled.

The final append is serialized and marked in the run KV store. Migration uses a non-final record and retains progress. Before the platform timeout, the Actor reserves roughly 15 seconds to checkpoint and finalize. A forced kill or storage outage can prevent any final write: there is no absolute exactly-once guarantee across separate network/storage operations. AUDIT_PENDING retains a sanitized recovery copy, and an ambiguous append is not blindly repeated. Audit storage failure is surfaced, not silently discarded.

Resume without replaying saved rows

Progress is saved in STATE in the run's key-value store. On Apify, migration/resurrection must retain the same run, dataset and key-value store for this recovery path. The dataset rebuilds deduplication sets after an interrupted write. Counters are cumulative for that job, and completed or failed accounts are not automatically restarted.

A new run normally receives new storage and starts a new extraction. There is no cross-run continuation-token input. Do not run two workers against the same storage, and do not share STATE because it contains private continuation state.

Compatibility: this revision uses checkpoint schema 2. The older private build 0.0.1 used per-relation result limits and checkpoint schema 1. Use fresh storage when moving from that build; old checkpoints are rejected rather than silently changing billing or result limits.

Build 0.0.2 allowed a combined relationship mode. Its combined-mode checkpoints cannot resume under a single relationship; use fresh storage instead. Single-relationship schema-2 checkpoints remain compatible when the accounts and selected relationship are unchanged.

Recommended timeout

These are conservative starting settings, not measured completion guarantees. Size means total requested records across all source accounts. Increase for many sources, retries or slow responses, while keeping a bounded timeout and run budget.

Requested total	Suggested timeout
Up to 100	5 minutes
Up to 1,000	20 minutes
Up to 5,000	60 minutes
Larger / unlimited	Stage the work into bounded runs or resumptions; estimate from a small pilot first.

For planning, approximately pages x observed response time + retry waits + storage overhead is needed. In our small live sample, later pages usually contained only 10 profiles. If no next page is accessible, increasing the timeout cannot reveal additional results. Large-result throughput and cloud migration have not been live-validated for this revision.

Known limits

In a small live sample, followers pagination worked across seven pages for neeturaj2525. meta, mosseri and zuck returned approximately 50 followers without a next cursor. Following pagination worked for those tested accounts. Pages could overlap and were generally 10 profiles after the first. These observations do not prove a universal verified/business-account restriction or complete audience accessibility.

Do not assume unlimited follower downloads, fixed page sizes, access to private targets or full audience completeness, especially for large accounts. Results reflect the public profiles accessible at extraction time; they are not a guaranteed complete list.

Responsible use and support

Use public data for lawful purposes, follow applicable platform terms, and retain only what is necessary. This Actor does not bypass private-profile controls. Contact scraping_solutions with your run ID and sanitized summary; never share credentials, cookies or STATE, which contains private continuation state.