Threads Reply Scraper — Conversation Graph

What this Actor scrapes

You pass one or more Threads post URLs. For each post, this Actor:

1. Fetches https://www.threads.net/@{username}/post/{code} with a real browser fingerprint. 2. Extracts the server-rendered conversation payload Threads embeds inside <script type="application/json" data-sjs> blocks. 3. Walks the payload's edges -> thread_items tree and emits one flat row per node — the root post plus every reply Threads inlined into the initial HTML, including nested chains (depth 2+).

What we handle for you

• Full reply tree per post — root + every reply chain Threads server-renders into the initial HTML, including nested depth-2/3+ chains.
• Depth-linked output — depth + parent_reply_id let you rebuild the conversation graph trivially in SQL, pandas, or networkx.
• Engagement counts on every node — likes, direct replies, reposts, and quote-posts captured per post and per reply.
• Media, mentions, and hashtags — every node ships its attached images/video (media, with alt text when Threads provides it), @mentions, and #hashtags — parsed straight out of the same payload, no extra request.
• We rotate browser fingerprints — curl-cffi Chrome 131 TLS + HTTP/2 impersonation so the target sees a real browser, not Python. Fingerprint profiles cycle per session.
• We rotate residential proxies — the RESIDENTIAL pool is on by default; fresh session ID on every block. Meta bans datacenter IPs within minutes; we route around it.
• We retry with exponential backoff — up to 5 attempts per URL on 408 / 429 / 5xx with Retry-After honoured. You get results, not empty datasets.
• Per-post cost control — maxDepth (1–10) and maxRepliesPerNode (1–500) caps so you pay exactly for what you need.
• Pydantic v2 input validation — bad URLs, empty lists, and out-of-range caps fail fast before any network call, not after you've paid for a run.
• Clean typed rows — ISO 8601 timestamps, stable pk-based IDs, nullable fields declared — no surprise nulls or mixed types in your dataset.

Use cases

• Brand reputation monitoring — pull the entire reply pile-on under a viral brand mention and triage by like count or reach in 2 minutes, not 90.
• Crisis communications — export every visible reply to a controversial post for PR review without manual scrolling.
• Social-listening dashboards — feed conversation-graph rows into Slack, Looker, Tableau, or Hex for real-time sentiment tracking on Threads.
• Competitive intelligence — track reply sentiment under competitor product launches on Threads.
• Creator analytics — see which of your own replies sparked sub-conversations vs which died after one comment.
• Academic research — bootstrap conversation-tree datasets for NLP and argument-mining models from public Threads discussions.
• Meta-policy research — measure conversation topology on policy-adjacent posts (fanout, nested-debate sub-threads, engagement decay).
• OSINT investigation — track public discussion threads around named events or accounts.

Input

Paste this into the Apify Console, or send it as the run input over the API. Proxy settings are on by default; you rarely need to touch them.

{
  "postUrls": [
    "https://www.threads.net/@mosseri/post/DYX3oNcAO4r"
  ],
  "maxDepth": 3,
  "maxRepliesPerNode": 50,
  "useProxy": true
}

Output

One row per result, schema-validated before it is written. Export JSON, CSV, Excel or XML from the run, or read it over the API.

root_post_idparent_reply_iddepthauthor_usernamereply_textmediamentionshashtagsview_countlike_countreply_countposted_at

{
  "row_type": "post",
  "root_post_id": "3897828658278100523",
  "root_post_url": "https://www.threads.net/@mosseri/post/DYX3oNcAO4r",
  "parent_reply_id": null,
  "reply_id": "3897828658278100523",
  "reply_url": "https://www.threads.net/@mosseri/post/DYX3oNcAO4r",
  "reply_text": "Does DMing people back help with reach?",
  "author_username": "mosseri",
  "author_display_name": "Adam Mosseri",
  "author_user_id": "63482099442",
  "author_followers": null,
  "posted_at": "2026-05-15T13:36:48+00:00",
  "like_count": 427,
  "reply_count": 98,
  "repost_count": 12,
  "quote_count": 2,
  "depth": 0,
  "media": [],
  "mentions": [],
  "hashtags": [],
  "view_count": null,
  "scraped_at": "2026-05-16T12:00:00+00:00"
}

Pricing

You pay only for results that land. Cap any run with maxTotalChargeUsd. See pricing & billing for worked examples.

Limitations

• No "Show replies" pagination. Threads gates deeper reply pagination behind an actual login wall for logged-out visitors — a live check against two high-reply-count posts found no client-side "show more replies" request at all; Threads renders "Log in to see more replies" in its place. Since this Actor deliberately never authenticates as a Meta account (that's the whole point of "no Meta login"), there is no unauthenticated endpoint to call here — this isn't a missing feature so much as the wall itself. This Actor emits exactly what threads.net/threads.com serves anonymously in the initial HTML: the root, all direct replies, and any inline-expanded depth-2/3 chains Threads already included there.
• No reposter user list. Threads renders the /reposts/ sub-page entirely client-side from a private endpoint using rotating tokens. Repost _counts_ are captured on every row (repost_count), but the list of accounts that reposted is out of scope.
• No quote-post bodies. quote_count is captured per row; the bodies of quote-posts referencing the input are not included.
• view_count is usually null. Threads' public view-count card is opt-in and rarely populated on the posts we've observed live; when it's present the Actor extracts it, when it isn't view_count is simply null — same nullability pattern as author_followers.
• External link-preview cards and video transcripts are not extracted. media covers images/video attached directly to a node; link-preview cards (title/domain of a shared URL) and auto-generated video transcripts are out of scope.
• Private profiles / login-walled posts return zero rows. If the page returns a login wall instead of the conversation payload, the Actor logs a WARNING and skips that URL. Enable useProxy to maximise success rate.
• Very large batches may encounter rate-limit windows. With residential proxy and per-URL session rotation the Actor handles single-post scrapes reliably. Batches larger than 20 posts in one run may trigger short pauses — we retry with exponential backoff up to 5 attempts per URL.
• Not real-time. The Actor reads what threads.net serves in its current SSR HTML. Replies posted seconds before the scrape may not yet be inlined in that snapshot.
• Apify FREE plan retains run-scoped storage for 7 days only. Export your dataset immediately after the run or use a named dataset to retain longer.
• ToS responsibility. Meta's Terms of Service prohibit scraping. The threads.net post URL is publicly accessible without login, but you remain responsible for verifying your jurisdiction's data-protection rules and Meta's current Terms before using scraped data commercially.