All-in-one 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.
Fixed runs finishing with zero results when the account they authenticated with had been suspended by Threads. A suspended session is indistinguishable from a healthy one by page content — same HTTP 200, same viewer data — and was accepted as valid, after which every request was silently answered with the block screen instead of data. The suspension is now detected by the URL Threads redirects to, the account is taken out of rotation with that reason, and the run continues on the next account in the pool.
The run now survives more dead accounts before giving up (5 instead of 3), because accounts get suspended in batches.
An account that gets suspended in the middle of a run no longer breaks the whole run: it is flagged and dropped, server-rendered pages continue without a session, and the modes that genuinely require one (followers, following) say so explicitly instead of reporting an empty list.
Fixed Expecting value: line 1 column 1 (char 0) being the only thing in the log when the API answered with something other than JSON. The status, content-type, URL and start of the body are now logged, and responses that cannot be fixed by retrying (a blocked or logged-out session) fail immediately instead of burning five attempts per request — which is what turned one bad account into hundreds of pointless requests.
Added backoff for HTTP 429: Retry-After is honoured, the whole run slows down together and speeds back up as requests succeed. Rate limits are counted per session, so retrying on a new IP alone never cleared them.
Search queries containing &, # or + are now escaped and no longer search for a truncated phrase.
0.3 (2026-07-30)
New input useOurAccounts (on by default): the run authenticates itself with a logged-in Threads session from our own account pool, so user_followers, user_following and pagination work without you supplying any cookies.
An account is leased to one run at a time and returned to the pool when the run ends — two runs never share the same Threads session. The lease is renewed while the run works, so a crashed run releases its account instead of holding it.
Accounts whose cookies Threads no longer accepts are flagged with the reason and taken out of rotation automatically, and the run continues on the next available account.
Your own threadsCookies still take priority: when that field is filled, the shared pool is not touched.
0.2.1 (2026-07-30)
Fixed posts and replies being reported as "not found" on pages that were actually fine: a truncated HTTP response (HTTP 200 with an incomplete body) left the last embedded JSON block broken, and the parser silently returned nothing. Truncated responses are now detected and retried on a fresh IP, and broken JSON blocks are logged instead of ignored.
Fixed the post parser picking the wrong edges list: the thread is not always the first one on the page, so a valid post could be missed. All candidate lists are now scanned.
All requests now go to www.threads.com directly instead of www.threads.net. The .net → .com redirect made curl drop the session cookies mid-redirect, so authenticated runs were silently anonymous, and the extra hop through a residential proxy sometimes collapsed into a redirect loop (curl 47).
Cookie verification now checks that Threads actually accepted the session (the viewer id is present in the page), instead of assuming success whenever a session cookie and an LSD token exist.
A network failure during cookie verification no longer discards the session: cookies are kept for SSR requests and only GraphQL pagination is disabled for that run.
post_replies with cookies no longer returns fewer replies than an anonymous run: replies from the server-rendered page are kept and merged with the GraphQL pages, deduplicated by post id.
Fixed a crash in paginated user_posts when a profile page came back without the expected posts block.
0.2 (2026-07-28)
New actions user_followers and user_following: scrape a profile's followers or the accounts it follows, each user as a separate dataset result, capped by maxItems.
Follower / following pagination via the private /api/v1/friendships/ web API, with deduplication across pages (Threads re-ranks the list between requests, so raw pages overlap).
Both actions require threadsCookies — Threads serves these lists only to logged-in sessions. Without cookies the run logs an explicit error and returns no items instead of failing.
Profile output now includes profile_url, instagram_url, instagram_user_id and recent_views_count. Follower / following results carry the same Threads and Instagram links.
New "Followers / Following" dataset view; the Profiles view now shows the linked Instagram account.
0.1 (2026-07-07)
Scrape Threads.net by search keyword, user profile, single post, user posts, and post replies.
Full pagination for search results, user posts, and post replies via the authenticated GraphQL API (SSR first page + cursor paging).
Rich post output: post_id, code, text, taken_at, media_type, like_count, reply_count, repost_count, quote_count, reshare_count, images, video_versions, carousel_media, text_fragments, post_url, and more.
Profile output includes biography, follower_count, is_verified, bio_links, bio_link_urls, profile_tags, and HD profile pictures.
Automatic extraction of emails and URLs from post text and profile bios.
Three dataset views (Overview, Profiles, Engagement) for quick browsing in the Output tab.
