Threads passed half a billion monthly actives in mid-2026, according to Instagram's Adam Mosseri, who posted the announcement himself. It is no longer a ghost town bolted onto Instagram: product teams, journalists, and brands post there daily, and a growing share of public conversation happens only on Threads, not mirrored anywhere else.
Reading it programmatically is where things get awkward. Meta ships an official Threads API, but it is built for managing the account you authenticate as, not for reading arbitrary public profiles. If you need to pull a competitor's posts, search keywords across the platform, or resolve a handle to the person behind it, you need a different approach.
This guide covers the Social Fetch /v1/threads/** routes: profile lookups, profile post lists, search, and single-post fetches, with real response data and the limits you will actually hit, including no pagination on profile posts and a metrics object that shrinks when you trim.
You'll need an API key and curl or the TypeScript SDK. New to the API? Start with the Quickstart.
What Meta's own API covers
Meta publishes an official Threads API of its own. It is account-scoped: you authenticate as a specific account, and from there you can publish posts, read that account's own posts and replies, and pull insights for it. That is the right tool for building a posting or scheduling product.
What it does not do is give you open read access to public profiles you do not own, or a keyword search across public Threads posts. If you want to track a competitor, monitor mentions of a product name, or hydrate a handle you found somewhere else, the official API has no route for that. That gap is why teams reach for a data API instead.
Check Meta's docs before you build
Meta's platform terms and product surface change often. Confirm current scope and rate limits in Meta's own developer docs before you commit to an integration plan.
Read a profile
A profile lookup returns the public fields for one handle. Here is zuck:
Look at the metrics object: followers is the only number Threads gives back on a profile. There is no post count and no following count. Docs: Get Threads profile.
List a profile's posts
The same call in the TypeScript SDK:
Docs: List Threads profile posts.
Always trim on Threads
The untrimmed version of that same 15-post call for mosseri came back at roughly 485,000 characters. Threads attaches full media variant arrays and a nested author block to every post when you do not trim, and across 15 posts that adds up fast. Trimmed, the same response is a small fraction of that size.
The trade-off: trimming reduces metrics down to likes only. If you need replies, reposts, or quote counts, do not trim. And as with any platform on this API, do not trim your first capture of a profile if you are storing author or baseline fields for later comparison; trim only on the polling calls after that.
trim=true changes what you get back
On Threads specifically, default to trim=true unless you need full media variants or metrics beyond likes. It is the difference between a response you can log comfortably and one that is not.
There is no cursor
GET /v1/threads/profiles/{handle}/posts takes exactly two parameters: handle and trim. No cursor, and no page object in the response. You get a recent window of posts, not a paginated archive.
That is a real difference from most other list routes on this API, which return page.nextCursor and page.hasMore so you can walk back through history. Threads does not offer that here. If you need a longer history for an account, the only option is to poll on a schedule and store what you see each time, the pattern covered in Social media monitoring with webhooks.
Search posts and users
Two separate routes, one for post content and one for accounts.
search takes query plus optional startDate and endDate, so you can bound a keyword sweep to a launch window or an incident. searchUsers takes only query; there is no date filter for accounts since accounts do not have a publish date.
Docs: Search Threads posts and Search Threads users. Both are 1 credit per completed call, same as every other Threads route.
Threads is Instagram underneath
A few details in the response data give this away. The platformUserId on a Threads profile is an Instagram-style numeric ID (63055343223 for zuck, 63482099442 for mosseri). Post shortcodes like Db_AU3kFko7 use the same alphabet and length as Instagram post shortcodes. And a Threads handle matches the linked Instagram handle, because a Threads account is created from an existing Instagram account rather than registered separately.
The practical consequence: a Threads handle is a reliable bridge to the same person's Instagram presence. If you are resolving creators across platforms, Threads is an unusually good hop, more reliable than guessing from a display name. See Cross-platform creator profiles and Linktree API for the rest of that identity-resolution chain.
Use Threads as an identity bridge
If you already have an Instagram handle and need to check whether someone posts on Threads too, or the other way round, a Threads profile lookup is often faster than trying to match display names across platforms.
Normalise the URL host
Look closely at the two hosts in the responses above. The zuck profile lookup returned profileUrl on .net: https://www.threads.net/@zuck. The mosseri post URLs came back on .com: https://www.threads.com/@mosseri/post/Db_AU3kFko7. Threads moved to the .com domain at some point, and both forms show up in live responses depending on the endpoint.
If you are using a post or profile URL as a database key, or doing plain string comparison to detect duplicates, normalise the host first. Otherwise the same post looks like two different rows the moment one lookup returns .net and another returns .com.
What you can build
A profile and search combo like this covers a handful of recurring jobs. Tracking a competitor's product announcements without babysitting their feed by hand. Resolving an Instagram creator's Threads presence for an outreach or partnerships list, using the identity bridge above. Watching for keyword mentions of a brand or product name as a lightweight brand-safety check. Feeding public discussion into a sentiment analysis pipeline alongside comments pulled from other platforms.
Because there is no historical archive on profile posts, anything that needs a timeline over weeks or months has to poll on a schedule and persist results as it goes, which is exactly what scheduled monitoring with webhooks is built for.
Limits worth knowing
| Limit | What it means |
|---|---|
| No pagination on profile posts | handle and trim are the only parameters; there is no cursor or deep archive |
| Profile metrics are followers-only | No post count and no following count in data.metrics |
| Trim drops metrics to likes | Replies, reposts, and quote counts require an untrimmed call |
| Public accounts only | Private Threads accounts will not return post or profile detail beyond what is public |
| No historical archive | Store what you pull; a later poll will not backfill what you missed |
| Threads changes fast | Domains, fields, and limits have moved before, see the host note above, and can move again |
FAQ
Is scraping Threads legal?
It depends on your jurisdiction, what data you collect, and how you use it. Collecting publicly visible profile and post data for analytics or research is a common pattern. You are still responsible for complying with Meta's terms, applicable privacy law, and your own contracts. This is a technical guide, not legal advice, talk to counsel if you are collecting at scale.
Does Social Fetch use Meta's official Threads API?
No. Meta's official Threads API is account-scoped and built for publishing and managing an account you authenticate as. Social Fetch reads public profile, post, and search data the way a browser or app would see it, which is what makes open lookups on arbitrary public handles possible.
Can I get a Threads profile's full post history?
Not in one call. The profile posts route returns a recent window with no cursor and no page object, so there is no way to page back through months of history in a single request. If you need a longer timeline, poll on a schedule and store what each call returns.
Why do some Threads posts only show a likes count?
That happens when you request the trimmed response with trim set to true. Trimming keeps the payload small by reducing the metrics object to likes only. Leave trim off if you need replies, reposts, or quote counts.
How are credits charged for Threads lookups?
Credits charge when a lookup completes, one credit per profile, profile posts page, search call, or single post fetch. Every response carries meta.creditsCharged so you can reconcile usage against what you expected to spend.
What happens if a Threads handle doesn't exist?
Check data.lookupStatus rather than assuming an HTTP 200 means the account was found. A missing or deleted handle can still return 200 with a lookupStatus that tells you nothing was there, so handle that case in your own code.
Can I search Threads posts by date range?
Yes, for post search. The search endpoint accepts optional startDate and endDate parameters so you can bound a keyword sweep to a specific window. The user search endpoint only takes a query, since accounts do not have a publish date to filter on.
How does this compare to Meta's official API or DIY scraping?
Meta's official API covers only the account you authenticate as: posting, replies, and insights for that one account. DIY scraping can work for a personal script but you own auth, endpoint changes, and field drift yourself. A data API like this one is built for reading public profiles and posts across many accounts without maintaining that scraping layer yourself. See the compare hub and vs Apify for specific vendor comparisons.
Next steps: Cross-platform creator profiles · Compare vs Apify · Quickstart · Pricing