Threads Scraper

Pull posts off Threads with the numbers that matter: likes, replies, reposts and quotes, plus the text, the timestamp, the media and the link preview. No login, no cookies to supply, no token to keep alive.

It works four ways, and you can mix all four in a single run.

The four modes

A profile. Give it zuck or @zuck and you get that account's recent posts along with the profile itself: follower count, full name, biography and verification status. Roughly ten posts per profile, which is what Threads renders on a profile page.

One post and its replies. Paste a post URL and you get the post plus every reply rendered underneath it, usually around thirty rows. This is the mode for reading a conversation rather than a feed, and each reply carries its own engagement counts so you can see which answer actually landed.

A keyword search. Give it a phrase such as web scraping and you get around twenty matching posts from across Threads.

A hashtag. Give it #ai and you get the posts filed under that tag.

Leave the mode on Auto and each entry decides for itself. A bare word is tried as a handle first and then as a search, so apify returns posts about Apify rather than an error when no such account exists. Every row records which reading produced it in source_mode, so you always know what you are looking at.

What each post gives you

• text, posted_at (ISO 8601) and posted_timestamp
• like_count, reply_count, repost_count, quote_count, reshare_count
• username, user_id, is_verified
• media_kind (text, image, carousel or video), plus image_urls and video_urls. Images come back at the largest published resolution rather than the thumbnail, because the thumbnail is rarely what anyone wants.
• link_url and link_title when the post carries a link preview card
• is_reply, so you can separate original posts from replies in one filter
• language, as detected by Threads itself
• is_paid_partnership, which is the disclosure flag on sponsored posts
• url, a direct link back to the post

Profile runs additionally carry profile_follower_count on every row, and the run summary holds the full profile records.

What the run summary tells you

Targets requested, targets that produced posts, total posts, profiles found, total likes across everything returned, how many posts carried media, and how many were replies. Enough to sanity-check a run at a glance without opening the dataset.

The failure mode this was built to avoid

Threads answers HTTP 200 with a full-size page for a handle that does not exist. The response is around 315 KB, which is the same order of magnitude as a real profile. Neither the status code nor the size can tell the two apart.

An actor that trusted the status code would report every typo'd handle as a real account that simply has not posted, and you would never know. So liveness is decided on the profile data itself: a real account carries a follower count, and a page without one is reported as an error naming the handle rather than as an empty success.

This matters more than it sounds. Silent wrong answers are worse than loud failures, because a row that says "0 posts" looks like data.

Input

A list of targets, and optionally:

• Mode — force every entry to be read the same way, instead of Auto
• Maximum posts per target — an upper bound per entry
• Maximum targets — how many entries to process in one run
• Targets in parallel — how many to fetch at once
• Retries — attempts with backoff before an entry is reported failed
• Request from country — a two-letter code, when you want the page as it is served in a particular region

Notes on scale and honesty

Each target costs exactly one page fetch, and a run of fifty targets at the default concurrency finishes in seconds. There is no crawling, no pagination loop and no per-post follow-up request, so the cost is predictable.

What you get is what Threads renders on the page. That is around ten posts for a profile rather than the full history, and around twenty for a search. If you need a longer history, run a profile repeatedly over time and keep the rows: post_id is stable, so deduplicating across runs is trivial. The actor does not pretend to page deeper than the site actually serves, because an actor that quietly returned fewer rows than it implied would be the same class of problem as the one described above.

Counts are read at the moment of the fetch. Likes and replies on a fresh post move quickly, so two runs minutes apart will legitimately disagree, and that is the data rather than an error.

Deleted posts and private accounts return nothing, and are reported as errors naming the target rather than dropped from the output.