Is There a Threads API for Reading Public Posts?

Yes, but it is gated twice. The Threads API documents profile_lookup, profile_posts and keyword_search against public content, and until Meta approves your app those calls return only four Meta-owned accounts. Approved apps get 1,000 profile requests and 2,200 keyword queries per rolling 24 hours, and search results omit the author of every post.

Most write-ups about the Threads API describe it as publish-only, and that description is out of date. It matters because Threads passed 500 million monthly active users in June 2026, and a read API nobody believes exists is one almost nobody is using.

Everything below is quoted from Meta's own documentation, read on 2026-09-12, with links at the end.

Is there a Threads API?

There is, it runs on graph.threads.net, and it does considerably more than post.

The publishing half is what got written about: create a post, reply, delete, tag a location, read your own insights. That half is real, and it is the half every tutorial covers. The read half is the reason this page exists.

For reading other people's public content there are three endpoints and three permissions worth knowing by name:

• threads_basic, "required for making any calls to all Threads API endpoints."
• threads_profile_discovery, which unlocks profile_lookup and profile_posts.
• threads_keyword_search, which unlocks keyword_search.

The permissions are the whole story. The endpoints exist for everyone. What they return depends on whether Meta has approved you.

Can the Threads API read other people's public posts?

Yes, within limits Meta publishes plainly.

GET /profile_lookup?username=... returns a public profile: username, name, profile_picture_url, biography, follower_count, likes_count, quotes_count, reposts_count, views_count and is_verified. The engagement counts are windowed rather than lifetime, covering the user's posts in the past 7 days.

GET /profile_posts?username=... returns that account's public posts.

Three restrictions decide whether this is usable for your product, and all three are documented:

Restriction	Meta's published wording
Follower floor	"Only returns public profiles with at least 100 followers."
Standard access	"With standard access, only some of the official Meta accounts can be looked up. These include @meta, @threads, @instagram, and @facebook."
Quota	"A user can send a maximum of 1,000 requests within a rolling 24-hour period."

The middle row is the one to plan around. Before App Review approval, the public-read endpoints are a demo. You can look up @meta and @threads and nothing else. Everything you build against them works perfectly and proves nothing about whether it will work for your users.

The follower floor is the second thing people trip over. A hundred followers excludes a large share of real accounts, so any feature that says "paste any Threads handle" will fail for a meaningful fraction of pastes, and it will fail in a way your test accounts probably will not reproduce.

And note the shape of the interface: it is keyed by username. There is no listing, no bulk export and no "give me accounts matching this description." You can look up an account you already know about. You cannot discover one.

What does Threads keyword search return?

Public posts, once you are approved, and the pre-approval behaviour is documented in a single sentence that is easy to misread:

"If your app has not been approved for the threads_keyword_search permission, the search will be performed only on posts owned by the authenticated user. After approval, public posts will be searchable."

So the endpoint never errors for an unapproved app. It quietly narrows its scope to your own posts and returns a well-formed, plausible, useless result. That is the same failure shape as a request that returns 200 and nothing you can use, and it will survive a code review because nothing is obviously wrong.

The search itself takes search_type of TOP or RECENT, and search_mode of KEYWORD or TAG. The quota is generous by the standards of this category: "A user can send a maximum of 2,200 queries within a rolling 24-hour period," and "Queries which return no results do not count against this limit."

Then the detail that decides most product designs:

"The owner field is excluded and will not be returned."

You can search public Threads posts and the API will not tell you who wrote them. You get the text, the media type, the permalink and the timestamp. For sentiment or volume work that is fine. For anything that needs to attribute a post to an account, monitor a competitor, or build a creator index, the one field you need is the one field deliberately withheld.

The asymmetry is deliberate and it is worth noticing, because the endpoint does accept an author_username parameter that "Filters search results to include only posts created by the specified username." You can ask whether a named account posted about a keyword. You cannot ask who posted about it. That is a design for monitoring accounts you already care about, not for finding new ones.

There is also a content filter: "The API will return an empty array for any requests that include keywords that we have deemed sensitive or offensive." An empty array, not an error, so once again your client cannot tell refusal from absence.

What are the Threads API rate limits?

Published, and unusually clear. The overall ceiling is impression-based rather than fixed:

Calls within 24 hours = 4800 * Number of Impressions

Impressions means impressions your account's content received in the last 24 hours, with a documented minimum of 10. A quiet account gets a small budget. This is the same shape as Instagram's business-use-case limits and it has the same consequence: your API budget is a function of how popular you already are.

On top of that, per-operation quotas on a 24-hour moving window:

Operation	Limit
Posts published	250
Replies	1,000
Deletions	100
Location searches	500
Profile discovery requests	1,000
Keyword search queries	2,200

GET /{threads-user-id}/threads_publishing_limit reports current usage, which is the right way to schedule rather than counting in your own database and hoping the two agree.

What can the API only do for your own account?

Insights. The documentation is explicit that "The Threads Insights API allows you to read the insights from users' own Threads," and the metrics are the ones you would expect: views, likes, replies, reposts, quotes and shares per post, plus followers_count and follower_demographics at the account level. There is a hard floor on history: the since and until parameters "do not work for dates before April 13, 2024."

The line that results is a clean one, and worth holding on to when you are scoping a feature:

Threads gives you metrics about yourself and public facts about everyone else. Your own insights are rich and historical. Another account gives you a profile card, its public posts, and seven days of engagement totals. Nothing about demographics, nothing about reach, nothing the account itself would consider private.

Is Threads oEmbed a way to get post data?

No, and this one is worth testing rather than assuming, because the endpoint answers.

GET https://graph.threads.net/v1.0/oembed?url=... accepts a post URL in either the /@{username}/post/{media-shortcode} or the /t/{media-shortcode} form. Meta documents the response as exactly six fields: html, provider_name, provider_url, type, version and width.

Read that list again for what is missing. No post text. No author. No timestamp. No like or reply counts. Calling it against a real public post returns HTTP 200 and those six fields and nothing else, and the html value is a <blockquote class="text-post-media"> placeholder containing the Threads logo and the words "View on Threads," plus a <script> tag pointing at embed.js that fetches the real content in the reader's browser.

oEmbed is a documented way to display a post by URL. It is not a way to get one. If your plan involved calling oEmbed in a loop and parsing the HTML, there is nothing in the HTML to parse.

Can you read Threads without the API?

Partly. Open a post URL in a logged-out browser and you will see its text, date and counts, followed by a prompt to log in to see more replies. Fetch the same URL without a browser and you get roughly 270KB of HTML with no post text in it and not even an og:title. The page is client-rendered, so what a reader sees and what a plain request receives are two different documents.

What Threads publishes about automated access is much less ambiguous. From threads.com/robots.txt:

"Collection of data on Threads through automated means is prohibited unless you have express written permission from Threads and may only be conducted for the limited purpose contained in said permission."

The rules underneath are strict and selectively so:

• The catch-all is User-agent: * followed by Disallow: /.
• Fourteen named agents are fully disallowed: Amazonbot, Applebot-Extended, Brightbot, ClaudeBot, Google-Extended, GPTBot, PerplexityBot, PetalBot, Scrapy, uptimerobot, viberbot, YaK, Yandex and Yeti. The AI crawlers are named individually, ClaudeBot, GPTBot, PerplexityBot and Google-Extended among them.
• Roughly twenty crawlers are allowlisted individually, each with the same path denylist covering /accounts/, /ajax/, /logging/, /publicapi/, /query/, /settings/ and a few more.
• Googlebot and Bingbot alone get four extra denials: /*/c/, /*/comments/, /*/liked_by/ and /*/p/.

Now look at that last entry against the URL format. Threads post permalinks are /@username/post/{shortcode}. The pattern /*/p/ does not match /post/, so Googlebot is permitted on Threads post pages. And the same file declares fifteen sitemaps, including five tiers of profile sitemaps, a creator sitemap set, threads_high_potential_posts_sitemap.xml.gz and a hashtag sitemap.

Meta is actively pushing Threads posts into Google's index while blocking ClaudeBot, GPTBot and PerplexityBot by name and blocking everyone else with a wildcard. Whatever you think of that as policy, it is a clear statement of who is welcome to read Threads at scale, and it is worth reading before anyone on your team writes a fetch loop. Whether the data is public is a different question from whether you accepted terms to reach it, and robots.txt is one of the facts that question turns on.

How does this compare with Instagram's API?

Same company, same documentation style, genuinely different answers. Both columns come from Meta's own documentation.

Can you read this about someone else?	Threads API	Instagram API
Public profile by username	Yes, profile_lookup, 100+ followers, approval required	No username lookup; business discovery only
Their public posts	Yes, profile_posts, same gates	No
Account types covered	Any public Threads account above the follower floor	Business and Creator accounts
Search public posts by keyword	Yes, keyword_search, author omitted	No
Media by hashtag	search_mode=TAG on keyword search	Yes, 30 unique hashtags per rolling 7 days
Comments or replies on their posts	No	No
Their engagement counts	Yes, 7-day window	comments_count and like_count via business discovery
Embed one of their posts	oEmbed, display only	oEmbed, display only, App Review required

The headline is that Threads is the more open of the two on the read side, which is the opposite of what most people assume from the fact that it is the newer product. If you want the fuller picture of the other column, what Instagram's official API actually returns is its own page.

Is Threads covered by the EU ad transparency rules?

Not currently. The European Commission's list of designated Very Large Online Platforms, updated 7 September 2026, names Facebook and Instagram for Meta. Threads is not on it.

That matters if you were hoping for a Digital Services Act ad repository for Threads, because the DSA archives exist only where a platform has been designated. No designation, no Article 39 obligation, no mandated archive.

So can you build on it?

Work through it in this order, because the gates fail in a specific sequence.

1. Does your feature need the author of a search result? If yes, keyword_search is out, and you are on profile_posts with a username you already have.
2. Do you have the usernames already? Profile discovery is a lookup, not a search. If your product needs to find accounts, the API does not do that.
3. Are your target accounts above 100 followers? Below that, the endpoints return nothing, by design.
4. Will Meta approve you? Until they do, you get four Meta accounts. Budget time for App Review before you promise a launch date, and do not treat a working prototype against @threads as evidence of anything.
5. Do 1,000 lookups a day cover your volume? If you are monitoring a few hundred accounts daily, comfortably. If you are backfilling a market, no.

Steps 1 to 3 are the ones that kill projects, and none of them is a rate limit. They are shape problems: the API is built for an account managing its own presence and looking up accounts it already knows, not for discovery or for a dataset.

We sell an API that reads public Threads data, so we have an interest in that last paragraph and you should weigh it accordingly. If you do end up buying rather than building, the question worth settling first is not coverage but how the vendor bills the requests that fail, because on any defended platform that number moves your unit economics more than the headline rate does.

---

Sources, all read 2026-09-12. Threads API overview and rate limits · Threads profiles and profile lookup · Retrieve and discover posts · Keyword search · Insights · Get started and App Review · oEmbed reference · threads.com/robots.txt · Meta's 500 million monthly actives announcement · European Commission list of designated VLOPs

Meta ships changes to this API without much announcement, and the read endpoints are the newest part of it. Re-check the permission requirements and the quotas before you size anything against them.