Monitor Threads by keyword or hashtag

The threads-profile-search page targets a specific account: you give it a username and it returns that user's profile and recent posts. This page is the opposite starting point — you give it a keyword or hashtag and it finds posts across Threads that match those terms, regardless of who posted them. It also adds monitor mode, which re-runs a saved search on a schedule and returns only new matching posts. Use profile search when you know the account; use this when you are tracking a topic, brand, or tag.

Threads (Meta's X competitor at threads.com) supports searching public posts and topic tags on its public web. Meta also ships an official Threads API with a keyword_search endpoint, but that path requires OAuth login and is rate-limited (around 2,200 queries per user in a rolling 24 hours), and it is oriented around an authenticated app context. The backing actor instead reads the public Threads web cookie-free, so you do not need a token or login. Logged-in search on Threads itself may surface a fuller set, but public search returns real results.

Search mode takes keywords or phrases and returns matching public posts. Hashtag mode takes topic tags (Threads' version of hashtags) and pulls that tag's feed. Monitor mode is for scheduled runs: it stores a watermark of what it has already seen and, on each new run, returns only posts that have appeared since the last run for your saved search. Monitor is what turns a one-off search into ongoing brand monitoring, lead-gen, or trend tracking.

No. It is a query builder. You choose the mode, enter your keywords or hashtags, set limits, and preview a fixed example of the output shape so you know the dataset structure. A browser cannot fetch threads.com results directly because the page is not CORS-open to other sites. You copy the generated config into the backing Apify actor, which executes the scrape server-side and returns the dataset as JSON, CSV, or Excel.

Post records include the matched query, post id, username, full name, post text, timestamp, engagement counts (likes, replies, reposts, quotes), media type and media URLs, and the post URL. When reply trees are enabled, reply records add a depth and a parent post id. When contact extraction is enabled, author records add parsed emails, phone numbers, and bio links. A recordType field labels each row as a post, reply, or author.

Optionally, yes. Turn on contact resolution and the actor parses public bios for emails and phone numbers and collects bio links — useful for lead generation from people posting about your niche. Linktree resolution follows Linktree, Beacons, or Stan links from the bio to surface the destinations behind them. Both are opt-in because they add per-author processing and, on the actor, are priced as separate events. Only scrape and use public contact data in line with applicable terms and privacy law.

The actor is free to start, then pay-as-you-go using Apify platform credits on a pay-per-event model — there is no actor-specific free quota beyond Apify's own platform credits. The first 10 chargeable events per run are free. Indicative per-event pricing: a surfaced search result around $0.0025, a fetched reply around $0.0015, a monitor delta (new post detected) around $0.005, and a one-time author-contact extraction around $0.02 per unique author. A typical 50-post search runs roughly $0.13. Check the Apify listing for current pricing.

Build a search or hashtag config here, then on Apify set the actor's mode to monitor and create a schedule (for example hourly or daily). On each run, monitor mode compares against its stored watermark and writes only new matching posts to the dataset, so you get an incrementally updated feed instead of re-fetching everything. Pair it with Apify integrations to push new matches to Slack, a webhook, or a sheet for live brand or trend alerts.

Scraping publicly available web data is generally treated as lawful in the US — the Ninth Circuit's hiQ v. LinkedIn ruling held that scraping public web data does not violate the CFAA. However, Meta's Terms of Use restrict automated collection, and GDPR or similar laws apply when you process personal data of EU residents, which is especially relevant if you extract author contacts. Scrape only public data, keep request rates reasonable, and review the relevant terms before commercial use. This is not legal advice.

Public, cookie-free search reads what Threads serves to anonymous visitors, so it does not deep-paginate an unlimited archive — set realistic per-query caps rather than expecting an exhaustive backfill of every historical post for a term. Logged-in or official-API search may surface a fuller set. Private accounts are out of scope, and very deep nested reply chains can be partial. The actor is honest about these bounds; use monitor mode going forward to capture new posts reliably rather than trying to scrape the entire past.