Pricing

from $5.00 / 1,000 reply tree row emitteds

Try for free

Go to Apify Store

Threads Reply Scraper — Conversation Graph

Try for free

Export the full reply tree of any public Threads post — no Meta login — as a conversation graph plus engagement counts, to JSON or CSV. A Threads post scraper built on the threads.net SSR HTML payload. We retry and rotate so the thread lands. Also a Threads comments scraper. Instagram Threads tool.

Pricing

from $5.00 / 1,000 reply tree row emitteds

Rating

0.0

(0)

Developer

DevilScrapes

Actor stats

Bookmarked

Total users

Monthly active users

4 days ago

Last modified

[0.7.2] — 2026-09-24 (fix: Relay payload schema migration — every run was failing, proxy or not)

Fixed

Root cause (CEO daily report: 73% 30-day success, 19/72 failed; build 0.7.1 15 days live): reproduced directly with two fresh cloud runs against build 0.7.1 — useProxy: true (the schema default) and useProxy: false (the QA fixture's setting) both FAILED, 0 rows, after exhausting all 5 rotate-and-retry attempts as "soft block: HTTP 200 without a usable payload." Both are false positives — Threads restructured the logged-out post page's SSR JSON between 2026-09-09 and 2026-09-24, and extract_conversation_payload()/_walk_to_edges() could no longer find result.data.data.edges anywhere in the response, so every real 200 response was misclassified as a login-wall soft block and the retry/rotation machinery burned through all 5 attempts on posts that were never actually blocked.
New shape (verified live via a local curl-cffi capture, @mosseri/post/DYX3oNcAO4r, 2026-09-24): the conversation is now split across two separate data-sjs scripts instead of one. Root post: result.data.media is the full post object directly (same field names as before — pk, user, caption, text_post_app_info, video_versions, etc.). Replies: a separate script's result.data.media.text_post_app_info.direct_replies.edges[i].node.posts.edges[j].node holds the reply-chain nodes (same chain-depth concept as the old thread_items, renamed and one hop deeper).
Fix: src/parser.py rewritten to parse every data-sjs script, walk each to result.data.media, and classify structurally (root = has pk+user; replies = has text_post_app_info.direct_replies.edges) rather than by literal marker substrings (BarcelonaPostPage/thread_items), which no longer reliably identify either script. extract_conversation_payload() now returns {"root": <post>, "reply_edges": <edges>}; walk_threads() and _rows_from_thread_chain() updated to match. _post_to_row(), _extract_media(), _extract_view_count(), _extract_handles() are unchanged — the individual post-object field shape did not move, only its location in the payload tree did.
tests/test_parser.py / tests/test_parser_media.py: _payload()/_edge() test helpers rebuilt to the new two-script shape; test_extract_payload_merges_root_and_replies_scripts and test_extract_payload_root_only_no_replies_script replace the old single-script test_extract_payload_picks_correct_script. tests/test_main.py::_minimal_valid_payload() updated to match.
tests/fixtures/input.qa.json: useProxy flipped false → true (the schema default, and what customers actually run). It had tested the no-proxy path exclusively since this Actor's first QA fixture — every prior cloud QA PASS, including 0.7.1's, verified a path most customers don't take. Both paths are confirmed fixed (see reproduction above), so this closes the coverage gap rather than papering over it.
64/64 hermetic + 1 live -m smoke green; ruff + pyright clean. Local apify run --input-file=tests/fixtures/input.qa.json (now useProxy: true) against the live target: 7 rows, no retries needed — confirms the fix, not just a proxy workaround.

[0.7] — 2026-09-09 (upgrade: media / mentions / hashtags / view_count — closes 3 of the 4 competitive gaps vs. the direct incumbent)

Added

Rationale (research/2026-09-09-upgrade-lane-top-earners.md, "threads-reply-tree" section, briefs 5+6): the direct incumbent in this niche, futurizerush/threads-replies-scraper (1,338 users, 305 u30 — proof this exact niche pays for these fields), leads its listing with media metadata, mentions/hashtags, and post view counts. This Actor previously shipped none of them.
src/models.py — new MediaItem model (type: "image"|"video", url, alt_text) and four new ResultRow fields: media: list[MediaItem], mentions: list[str], hashtags: list[str], view_count: int | None.
src/parser.py — pure extraction functions, all reading fields already present in the SSR payload this Actor already parses (no new HTTP request):
- _extract_media() / _media_item_from_node(): reads video_versions (preferred) or image_versions2.candidates[0], with accessibility_caption as alt_text. Carousel-aware — carousel_media items are walked individually; a non-carousel post is treated as a one-slide carousel of itself.
- _extract_handles(): shared regex helper for both @mention and #hashtag extraction from reply_text, deduped in first-seen order.
- _extract_view_count(): best-effort read of text_post_app_info.public_view_count_card_attachment_info — root row only, null everywhere else (including when Threads doesn't publish the card, which was every live post captured during development; see Limitations).
.actor/dataset_schema.json updated with the four new fields (all optional/nullable — no change to required, so existing consumers reading old rows are unaffected).
tests/fixtures/live_post_media_mentions_hashtags.json — a real capture (curl-cffi chrome131 against https://www.threads.com/@zuck/post/DcwLClnmOrR, 2026-09-09), trimmed to the fields parser.py consumes: the root post (a real video attachment), one real reply with a #hashtag-only caption, and one real reply with an @mention. 9 new tests in tests/test_parser_media.py exercise both this live capture and synthetic edge cases (carousel media, no media, multiple mentions/hashtags in one caption, deduping).
63/63 hermetic + 1 live -m smoke green; ruff + pyright clean (one pre-existing, unrelated pyright finding in tests/test_main.py:48 predates this change and is out of scope here).

Investigated, not shipped

Nested "Show replies" expansion (brief 5) — infeasible for this Actor's architecture, not implemented. A live Camoufox recon (recording all threads.net/threads.com XHR/GraphQL requests while attempting to trigger "Show replies" on two high-reply-count posts, @zuck/post/DctzKbqgOUy and @mosseri/post/DYX3oNcAO4r) found zero such requests fired. Instead, the DOM renders a literal "Log in to see more replies." wall in place of any expansion affordance for a logged-out session — confirmed via page.evaluate() scanning all div/span/a/button text and aria-label content, not just the visible viewport. There is no anonymous continuation endpoint to call: Threads gates deeper reply pagination behind actual authentication, not a client-side XHR this Actor could reuse on its existing curl-cffi session. Since this Actor's core value proposition is "no Meta login" (see the README H1 and FAQ), building real session-based authentication to unlock this would be a different, much larger, and ToS-riskier product than what's shipped today — out of scope for a "reasonable effort" attempt. Documented in README → Limitations. If a future pass wants to revisit this, it needs actual Meta session cookies, not a bigger XHR search.

Not changed

No behavior change to the retry/backoff/rotation state machine (client.py), the residential proxy group, or existing fields (row_type .. depth, scraped_at) — this is a strictly additive schema change plus the brief-5 investigation above.

Fixed (published as build 0.7.1)

The pre-existing pyright finding in tests/test_main.py:48 noted above (line 14) is fixed in commit 5a88ed5e — uv run ruff check ., uv run pyright, uv run pytest -q, and uv run pytest -q -m smoke are all green.
Build 0.7.1 cloud QA PASS: runId=eNyBsEF3XifNYGF9a, 8/8 rows, chargedEventCounts actor-start=1/result-row=8, new media/mentions/hashtags/view_count fields present on every row (root row carries a real video in media). No PPE event or pricing change. Spend $0.000494 (well under $0.30 budget).

Fixed

Root cause (30-day success rate 79.5%, 14 users at the time; one consenting-user failure visible in Console Insights, run GgAvIfJGeJ5KPUxzY, 2026-08-26): 10:17:28 FAILED 0 rows 6s, 10:18:55 SUCCEEDED 22 rows 9s, 10:20:59 SUCCEEDED 22 rows 12s — same user, same post, 90 seconds apart. A dead/private URL does not start working 90s later, and 6s is far too short for MAX_RETRIES=5 with backoff to have actually run — it never ran. Meta serves a soft block as HTTP 200 with a login-wall body, not a 403/429, and ThreadsSession._attempt() returned any 2xx body as success. main.py then found no conversation payload in that body, returned [], and kept == 0 exited 1 (REQ-11) on the very first attempt — the retry and proxy-rotation machinery built in [0.3]/[0.4]/[0.5] never triggered because nothing had signalled a block in the first place.
Fix: fetch_post_html() in src/client.py takes an optional is_usable predicate; a 200 body the predicate rejects is now handled exactly like a 403 — rotate identity, back off, retry — and exhaustion raises RuntimeError naming the soft blocks. main.py supplies the predicate (payload extractable?) and caches the parsed payload so a usable body is still parsed only once. client.py stays parser-agnostic per its module contract (predicate injected, not imported). REQ-11 is unchanged: after 5 rotated attempts a run with zero rows is genuinely blocked and still exits non-zero.
3 new regression tests (recovers after a soft block; sustained soft block raises; no predicate preserves legacy behaviour). 54/54 hermetic + 1 live -m smoke green; ruff + pyright clean.
Shipped as build 0.6.2 (actor.json version field intentionally held at 0.6 — no input/schema/pricing change, so this rides the same top-level version per Apify's own build-number sub-versioning). Cloud QA: build 0.6.2, run TM755kSbA8Kxbaeu6 SUCCEEDED, 18 rows, chargedEventCounts={"actor-start": 1, "result-row": 18}.
Backfilled into this CHANGELOG + docs/specs/threads-reply-tree/notes.md on 2026-09-03 by actor-fixer triaging a fresh "79% success, 16/77 failed, 35 users" report — the code and cloud build were already live and QA-verified when found; this entry documents that shipped fix, no new code change accompanies it. See notes.md for the 2026-09-03 session writeup, including why no further code change was made this pass.

[0.6] — 2026-09-01 (fix: one malformed reply node crashed the whole walk instead of being skipped)

Fixed

Root cause (CEO daily report 2026-09-01: "30-day success rate 79% — 17 of 83 customer runs failed"; users=35, the highest of any Actor in the fleet). Build 0.5.1 has been live since 2026-08-21 (11 days before this report), so the 30-day window is dominated by runs against the current build — this is not a stale-report artifact. GET /v2/acts/{id}/runs again shows only our own 7 runs (all SUCCEEDED, build 0.5.1) — the 17 failures are invisible customer runs, so the bug was reproduced directly from the source rather than from logs we don't have access to.
Two highest-probability causes for this fleet were checked first (reference-fleet-fault-isolation-pattern, scripts/os/empty_is_not_failure.py):
- Empty-is-a-failure: ruled out. walk_threads always emits at least the root row unless the payload itself can't be parsed, so a genuinely-zero-reply post already scores kept=1, not kept=0 — main.py's SystemExit(1) on kept == 0 only fires when nothing at all could be scraped.
- Fault isolation: confirmed. src/parser.py::walk_threads called _post_to_row(...) directly for the root post and for every reply node in a thread chain. _post_to_row coerces fields like like_count / reply_count with a bare int(...) — any one node with a non-numeric/uncoercible field (a deleted-but-visible stub reply, a bot account with a weird counter, any schema-drift edge case) raised ValueError/TypeError/etc. uncaught inside walk_threads itself, discarding the root row and every other good reply for that post — not just the bad node. _scrape_one_url in main.py already isolates failures per post URL (tested,
  test_drain_inputs_one_bad_url_does_not_ sink_the_others
  ), but this Actor's default and most common usage is a single post URL, where that per-URL isolation does nothing. Reproduced directly: walk_threads on a 3-edge payload (root + good reply + reply with like_count="N/A") raised ValueError and returned zero rows for the whole post, confirmed locally before any code change.
Fix: src/parser.py — new _safe_post_to_row() wraps _post_to_row() and returns None (never raises) on
```
(ValueError, TypeError, KeyError, AttributeError, IndexError)
```
; both call sites (walk_threads's root row and _rows_from_thread_chain's per-item loop) now use it and skip the bad node instead of propagating. A skipped mid-chain node doesn't advance parent_id, so later nodes in the same chain correctly re-link to the last successfully-emitted ancestor instead of losing their place in the tree. A malformed root post still yields zero rows for that URL (there's no valid anchor to link replies to), but no longer raises — the URL is now cleanly skipped by _scrape_one_url's existing per-URL guard instead of crashing.
New regression tests in tests/test_parser.py: test_one_malformed_top_level_reply_does_not_crash_the_whole_walk, test_one_malformed_node_mid_chain_does_not_sink_the_rest_of_the_chain, test_malformed_root_post_returns_empty_instead_of_raising — all three fail on pre-fix code (reproduced), pass post-fix. 54/54 hermetic + 1 live -m smoke green; ruff + pyright clean; verify_input_prefill.py and verify_no_scaffold_stub.py both OK. A local apify run against tests/fixtures/input.qa.json against the live target produced 8 real, fully-populated dataset rows (not a zero-row false-green).
No change to the retry/backoff/rotation state machine in client.py or to the RESIDENTIAL proxy group set in [0.5] — neither was implicated by this reproduction.
Not verified in this pass (needs cloud QA + a few days of the fresh 30-day window): whether this fully accounts for all 17 failures, or whether a residual slice is proxy/anti-bot related. If success rate is still below expectations after this propagates, check for schema drift in the Relay payload shape itself (a _walk_to_edges miss returns [] silently and is not distinguished from "genuinely no conversation payload" in the CHANGELOG's own [0.2] framing) before touching rotation logic a third time.

[0.5] — 2026-08-21 (fix: proxy group was a small datacenter-ish USA pack, not residential — Meta was blocking the pool itself, not failing to rotate)

Fixed

Root cause (CEO report 2026-08-21: "30-day success rate ~72% — 18 of 66 runs failed"; unchanged from before the [0.4] 403-rotation fix shipped 2026-08-15, which fixed a real bug but did not move the success rate). GET /v2/acts/{id}/runs only returns runs started under our own token (3 total, all our own QA, all SUCCEEDED) — the 18 failures are invisible customer runs, so the bug had to be reproduced and the infra verified directly:
- A live cloud run against the exact Store-prefill input (build 0.4.1, useProxy: true, default depth/cap) — run Vg7vXsyrLiCcL27Ua — SUCCEEDED, but scripts/os/run_usage.py showed zero PROXY_RESIDENTIAL_TRANSFER_GBYTES billed against it, despite the code requesting a proxy on every run.
- GET /v2/users/me shows the Console labels BUYPROXIES94952 as "Proxies from USA 2" (27 IPs) — a small static/datacenter pack, not residential. RESIDENTIAL shows availableCount: 0 in the same response, which is the known cardinality display artifact (see memory reference-proxy-availablecount-trap / reference-residential-is-entitled), not a real entitlement gap — a local probe authenticated against both groups successfully.
- src/main.py::PROXY_GROUP was set to BUYPROXIES94952 since this Actor's original 2026-05-16 scaffold, when it was the only proxy group provisioned on the account (FREE tier). The account moved to STARTER on 2026-08-20, which provisions RESIDENTIAL, but nothing here was ever updated to use it — every "rotate on block" fix ([0.3], [0.4]) rotated within the same small non-residential pool. Meta blocks datacenter IPs aggressively (this Actor's own useProxy schema copy already said so) — rotating through 5-27 exits that are all in the same flagged range never produces a genuinely fresh identity. amazon-reviews-scraper — the sibling client.py explicitly says its retry/rotation logic mirrors — defaults PROXY_GROUP to RESIDENTIAL; this half of the pattern was never matched.
Fix: PROXY_GROUP = "RESIDENTIAL" in src/main.py. Updated the useProxy copy in .actor/input_schema.json, src/models.py, scaffold.json, and README.md — all previously advertised the BUYPROXIES94952 pool as "residential" by name, which was never true.
New regression test test_create_proxy_configuration_uses_residential_group — asserts _create_proxy_configuration requests groups=["RESIDENTIAL"]; fails on pre-fix code (groups=["BUYPROXIES94952"]), passes post-fix. 48/48 hermetic + 1 live -m smoke green.
No behavior change to the retry/backoff/rotation state machine in client.py — that logic (403+429 rotate, 408/429/5xx retry, per-URL fault isolation) was already correct; it was rotating within the wrong pool.

[0.4] — 2026-08-15 (fix: HTTP 403 never actually rotated — the 0.3 fix's core claim was unreachable code)

Fixed

Root cause (CEO report 2026-08-15: "30-day success rate 68% — 21 of 66 runs failed"; success rate did NOT recover after the 2026-08-10 [0.3] proxy-rotation fix — ops/reports/data/*.json shows success_rate_30d actually dropping from 0.734 (08-09, pre-fix) to 0.687/0.682/0.672 across the days immediately after 0.3 shipped, before a marginal recovery to 0.682 today). recent_failures on our own runs was empty of new signal (3 FAILED runs total, all either the pre-fix bug already documented in [0.3] or a deliberate own negative-input test), so the regression had to be found by code inspection plus a live cloud reproduction, not guessed.
src/client.py::ThreadsSession._attempt gated retries with if status not in RETRY_STATUSES: raise RuntimeError(...) before ever consulting ROTATE_STATUSES. RETRY_STATUSES is {408, 429, 500, 502, 503, 504} — it does not include 403. Since ROTATE_STATUSES = {403, 429} is only checked inside _handle_retriable_status, which is itself only reached after the RETRY_STATUSES gate passes, every HTTP 403 — Meta's most common anti-bot block signal, arguably more common than 429 for an already-flagged residential exit — raised immediately on attempt 1 with zero retry and zero rotation. The ThreadsSession rotation logic the [0.3] CHANGELOG entry credited with fixing the customer-failure spike was therefore unreachable for 403s the entire time; [0.3]'s own reproduction and cloud QA only exercised 429 and connection-timeout cases, never 403, so the gap shipped untested. Confirmed against actors/amazon-reviews-scraper/src/client.py — the sibling module this code claims to "structurally mirror" — whose equivalent gate correctly reads
```
if status not in RETRY_STATUSES and status not in ROTATE_STATUSES: raise
```
(i.e. a status in ROTATE_STATUSES can never be treated as non-retriable). threads-reply-tree had dropped the ROTATE_STATUSES half of that condition.
Fix: add and status not in ROTATE_STATUSES to the same gate, matching amazon-reviews-scraper. A 403 now reaches _handle_retriable_status, which rotates the browser-impersonation profile and mints a fresh Apify Proxy session_id before backing off and retrying — exactly the behavior the [0.3] docstrings already claimed.
New regression test test_retry_on_403_rotates_session (mirrors the existing test_retry_on_429_rotates_session) — fails on pre-fix code with RuntimeError: HTTP 403 ... (non-retriable), passes post-fix. 48/48 tests green (47 hermetic + 1 live -m smoke).
No behavior change for 404/400/401/410 (still immediately non-retriable, per test_no_retry_on_404) or for 429/5xx (unchanged).

[0.3] — 2026-08-10 (fix: fixed proxy session reused across every retry — sustained blocks failed the whole run)

Fixed

Root cause (CEO report 2026-08-10: "30-day success rate 69% — 20 FAILED of 68 customer runs"; 5 new failures landed since 08-06 on build 0.2.1). Our own runs mostly succeed (GET /v2/acts/{id}/runs only returns runs started under our token), so this had to be reproduced directly against the live Store build. Two throwaway cloud runs against the exact same real, currently-live post URL minutes apart: bmn46iJqvQeE47f68 SUCCEEDED in ~5s; NaX3kHbV8fQQNymwO hit five consecutive HTTP 429s from Threads and FAILED with exit 91 ("No rows emitted..."); a third run (BbQqCwfKct710S0ab) hit sustained curl: (28) Connection timed out on every attempt instead. In every case the log shows the identical failure repeating attempt after attempt with no change in outcome — because main.py opened one curl-cffi session (and therefore one fixed residential proxy exit IP) before the retry loop and reused it for every attempt and every URL in the batch. A blocked/rate-limited exit was retried against itself five times, in direct violation of the house anti-blocking rule ("rotate the session_id on every block"). Real content parsing was confirmed unaffected — six freshly-fetched real posts all parsed correctly during triage; this was purely a transport-identity bug.
src/client.py replaced the stateless fetch_post_html(session, url) helper with a stateful ThreadsSession that rotates the browser impersonation profile and mints a fresh Apify Proxy session_id on every 403/429/network-level error, before the next retry attempt. Structurally mirrors actors/amazon-reviews-scraper/src/client.py's AmazonReviewSession, an already-shipped instance of this exact pattern.
src/main.py now pins country_code="US" on the Apify Proxy configuration (feedback-pin-proxy-country) — defensive, since a geo-random exit can silently change what a target serves even without an outright error.
Added _guard_against_missing_replies: if a post's own direct_reply_count says replies exist but the walk captured none, the Actor now logs ERROR and dumps the raw conversation payload to the KVS (missing-replies-<id> key) instead of letting that look like a clean, complete scrape. Posts that genuinely have zero replies are unaffected.

[0.2] — 2026-08-05 (fix: threads.com URLs hard-rejected the whole batch)

Fixed

Root cause (CEO report 2026-08-05: "30-day success rate 76% — 13 FAILED of 56 runs"): recent_failures on our own runs was empty, so this had to be reproduced directly. Live check confirmed https://www.threads.net/... now 301-redirects to https://www.threads.com/... — Meta migrated the canonical share-link domain in 2024, and every "Copy Link" / address-bar URL a customer pastes today is threads.com. ActorInput.post_urls's regex only accepted threads.net, and Pydantic validates the whole list eagerly — a single threads.com URL anywhere in postUrls raised ValidationError and killed the entire run via SystemExit(1) before a single HTTP request was made. Reproduced locally with
```
apify run
```
: pre-fix, a threads.com-only input exits 91 (FAILED) inside ActorInput.model_validate; post-fix, the same input exits 0 with 7 rows scraped.
POST_URL_PATTERN now accepts both threads.net and threads.com.
ActorInput._normalize_urls no longer fails the whole postUrls batch on one malformed item (wrong domain, wrong shape, non-string). It skips the bad item with a logged warning and keeps every valid URL — matching the REQ-7 "fail loud only when nothing is left" pattern already used elsewhere in this Actor. Still raises when zero items in the batch are usable.
main._scrape_one_url now also catches unexpected parser exceptions (ValueError/TypeError/KeyError/AttributeError/IndexError) per-URL and skips that URL instead of letting a single malformed post object crash _drain_inputs for every other URL in the batch.
Updated input_schema.json description, the postUrls field description, and the README "Finding a Threads post URL" section to say both domains work.
No changes to the happy-path fetch/parse logic — threads.net still works unchanged (verified redirect + SSR payload extraction both succeed), and the QA fixture (threads.net) still scrapes 7 rows.

[0.1.0] — 2026-05-16

Added

Initial release.
HTML SSR extraction of Threads conversation tree via curl-cffi chrome131 impersonation.
Per-post reply tree: root + every visible reply chain, with depth
- parent_reply_id linkage for graph reconstruction.
max_depth and max_replies_per_node caps for cost control.
PPE pricing: $0.05 / start + $0.005 / row.
Residential proxy (BUYPROXIES94952) recommended ON by default.

Threads Full Scraper - Posts, Profiles & Replies | No Login

pro100chok/threads-scraper-usage

All-in-one Meta Threads.net scraper: search posts by keyword, extract user profiles with followers, and collect reply threads. Full engagement data, contact extraction, media URLs. 20 parallel workers, auto-retry, proxy rotation. No login.

Raven

856

4.9

(5)

Threads Post Detail Scraper

xtracto/threads-post-detail-scraper

Fetch a Threads post by URL or post code, including replies.

Farhan Febrian Nauval

Threads Replies Scraper

futurizerush/threads-replies-scraper

Extract public Threads post replies and comments with author info, available engagement metrics, media details, quote/repost signals, and verification status. The original post row includes public view count when available. Batch multiple posts with no login required.

Rush

1.8K

1.8

(2)

Threads Posts Scraper

logical_scrapers/threads-post-scraper

Threads Post Scraper extracts complete data from any public Threads.net post, including caption text, media, engagement metrics, author details, and all replies. giving you accurate and structured output ideal for research, analytics, monitoring conversations, and building datasets at scale.

Goldmine

1.8K

4.5

(10)

Threads Scraper - Threads, Post & Profile

thenetaji/threads-scraper

Paste Threads profile and post links together and export profile records or individual posts with their authors, media and public replies. No Threads login or account needed.

The Netaji

530

4.5

(5)

Threads Scraper - Posts, Profiles & Search

futurizerush/meta-threads-scraper

Search Threads posts by keyword, or grab any profile's posts, replies and reposts. Export engagement, views when available, and media. No login.

Rush

6.5K

4.2

(19)

Threads Replies Scraper API

futurizerush/threads-replies-scraper-api

Fetch replies from Threads posts. Get reply text, engagement metrics, author info, and media details. Requires a Threads Session ID.

Rush

169

5.0

(1)

Meta Threads Profile Scraper

apify/threads-profile-api-scraper

Scrape Threads profile info. Add one or more Threads usernames and extract number of followers, bio, profile details, URLs, picture URL, full name, username and more. Download structured data in JSON, CSV, XML, Excel, and HTML to use in applications and reports.

Apify

4.5K

5.0

(7)

Threads Replies Scraper

automation-lab/threads-replies-scraper

Extract public Threads post replies with author profiles, text, engagement counts, media URLs, nesting metadata, and timestamps.

Automation Lab

191

Threads Replies Scraper

igview-owner/threads-replies-scraper

Scrape public replies and comments from Meta Threads users. Get reply text, user info, engagement metrics and media URLs in clean JSON/CSV for analytics and research.

Sachin Kumar Yadav

149

4.0

(3)

Threads Reply Scraper — Conversation Graph

Changelog

[0.7.2] — 2026-09-24 (fix: Relay payload schema migration — every run was failing, proxy or not)

Fixed

[0.7] — 2026-09-09 (upgrade: media / mentions / hashtags / view_count — closes 3 of the 4 competitive gaps vs. the direct incumbent)

Added

Investigated, not shipped

Not changed

Fixed (published as build 0.7.1)

[0.6.1] — 2026-09-02 (fix: HTTP 200 login wall was treated as a successful fetch — retry/rotation never fired)

Fixed

[0.6] — 2026-09-01 (fix: one malformed reply node crashed the whole walk instead of being skipped)

Fixed

[0.5] — 2026-08-21 (fix: proxy group was a small datacenter-ish USA pack, not residential — Meta was blocking the pool itself, not failing to rotate)

Fixed

[0.4] — 2026-08-15 (fix: HTTP 403 never actually rotated — the 0.3 fix's core claim was unreachable code)

Fixed

[0.3] — 2026-08-10 (fix: fixed proxy session reused across every retry — sustained blocks failed the whole run)

Fixed

[0.2] — 2026-08-05 (fix: threads.com URLs hard-rejected the whole batch)

Fixed

[0.1.0] — 2026-05-16

Added

You might also like

Threads Full Scraper - Posts, Profiles & Replies | No Login

Threads Post Detail Scraper

Threads Replies Scraper

Threads Posts Scraper

Threads Scraper - Threads, Post & Profile

Threads Scraper - Posts, Profiles & Search

Threads Replies Scraper API

Meta Threads Profile Scraper

Threads Replies Scraper

Threads Replies Scraper

Changelog

[0.7.2] — 2026-09-24 (fix: Relay payload schema migration — every run was failing, proxy or not)

Fixed

[0.7] — 2026-09-09 (upgrade: media / mentions / hashtags / view_count — closes 3 of the 4 competitive gaps vs. the direct incumbent)

Added

Investigated, not shipped

Not changed

Fixed (published as build 0.7.1)

[0.6.1] — 2026-09-02 (fix: HTTP 200 login wall was treated as a successful fetch — retry/rotation never fired)

Fixed

[0.6] — 2026-09-01 (fix: one malformed reply node crashed the whole walk instead of being skipped)

Fixed

[0.5] — 2026-08-21 (fix: proxy group was a small datacenter-ish USA pack, not residential — Meta was blocking the pool itself, not failing to rotate)

Fixed

[0.4] — 2026-08-15 (fix: HTTP 403 never actually rotated — the 0.3 fix's core claim was unreachable code)

Fixed

[0.3] — 2026-08-10 (fix: fixed proxy session reused across every retry — sustained blocks failed the whole run)

Fixed

[0.2] — 2026-08-05 (fix: threads.com URLs hard-rejected the whole batch)

Fixed

[0.1.0] — 2026-05-16

Added