By Nikhil Kumar. Last updated August 2026.
You searched “Threads API key,” landed on Meta’s developer docs, and slowly realized it does not do the thing you wanted. You are not alone, and you are not wrong.
Threads has no public API in the sense most people mean. Meta’s official Threads API, launched in June 2024, is a publishing tool: you can post as yourself, read your own content, and see your own insights. It cannot read arbitrary public profiles, posts, or stats from accounts you do not own. To pull public Threads data you need a read API that reads the public web instead.
Does Threads have a public API?
No, not the one you are looking for. Meta ships an official Threads API, but it is scoped to accounts that authorize your app. There is no endpoint that takes any public handle and returns that account’s posts or a post’s engagement. The two routes to Threads data split cleanly: your own account goes through Meta’s publishing API, and any public account goes through a third-party read API.
That split is the whole confusion. People type “Threads API” expecting the second thing and find only the first.
If your job is scheduling your own posts, stop reading and go use Meta’s API. It is free and it is the right tool. If your job is reading Threads you do not own, keep going.
What can the official Meta Threads API actually do?
It publishes and manages your own account. Meta launched the Threads API on June 18, 2024, after a spring beta. You can publish single posts and carousels, fetch your own posts, run reply moderation, and read insights like views, likes, replies, reposts, and quotes at the media and account level, for your account.
The word doing the work there is “your.” Every read path is scoped to the authenticated account.
It is free, with no paid tier. According to Blotato’s breakdown of Threads API pricing, Meta publishes no per-call fee, and the limits are per profile in a rolling 24 hours: about 250 posts, 1,000 replies, and 100 deletions.
Look at those numbers. They are a posting quota, not a reading one. That tells you what the API is for before you read a single doc.
Why can’t you use the official API to read other accounts?
Because it was built to manage accounts, not to survey them. The API only reads content from accounts that authorize your app through OAuth, and even the keyword-search capability sits behind Meta app review with its own caps. There is no free, open endpoint that returns any public profile, its post history, or one post’s stats. Competitor tracking and agency reporting fall straight into that gap.
App review is the practical wall. To ship anything beyond your own account you submit your app, justify each scope, and wait.
And the scopes you would want for reading, like broad public discovery, mostly do not exist as products. Meta built Threads’ API for creators and tools managing a presence, so the read surface for other people’s public content stays deliberately thin.
This is not a bug you can work around with the official API. It is the design.
What Threads data can you still get?
The public stuff, through a read API that reads logged-out pages. Anything a visitor can see without signing in is fair to collect as JSON: a public profile, an account’s recent posts, a single post’s engagement counters, and a recent-first keyword search. ScraperSocial exposes five Threads endpoints that do exactly this, priced at 3 to 4 credits each, with no Meta app and no OAuth.
Here is the honest map of what each call gives you.
| Endpoint | Input | Returns | Credits |
|---|---|---|---|
| Profile | handle | Name, bio, follower count, verified flag, avatar, bio link | 4 |
| Posts | handle | An account’s recent posts, newest first | 3 per post |
| Stats | post URL | One post’s text and public counters | 3 |
| Search | query | Recent public posts matching a keyword | 4 per post |
| User search | query | Public accounts matching a query | 4 per account |
Two honest limits before you build. The profile call carries no post count, no following count, and no join date, because Threads does not expose them on the public profile. And search runs recent-first with no cursor, so limit is the whole depth control you get.
Why is there no Threads view count anywhere?
Because Threads keeps views private to the author. View counts show up only in the account owner’s own insights inside the app, and the June 2024 API confirms it by returning views at the account and media level for the authenticated user. They are never printed on the public post page.
So a logged-out reader cannot see a view count, and neither can any public read API.
I am blunt about this because the alternative is worse. If a tool shows you public Threads view counts, it is either signed in as that account or making a number up. Ours returns likes, replies, reposts, and quotes, and no views key at all.
That boundary is what keeps the read predictable. We read the same page you can, and we return only what is on it.
What does a Threads post look like in JSON?
A flat object with the text, the author handle, four public counters, a timestamp, and two booleans. The counters are likes, replies, reposts, and quotes. The booleans, is_reply and is_repost, matter more than they look, because a Threads permalink to a reply looks identical to one for a top-level post, so is_reply is often the first field your code should branch on.
import requests
r = requests.get( "https://api.scrapersocial.com/v1/threads/stats", params={"url": "https://www.threads.com/@mosseri/post/ABC123"}, headers={"Authorization": "Bearer sk_live_..."},)post = r.json()["data"]print(post["author"], post["likes"], post["quotes"], post["is_reply"])# note: there is no post["views"] key; Threads does not publish itEvery response is wrapped in the same { data, meta?, request_id } envelope as the rest of the API, so a Threads call parses the same way a TikTok or LinkedIn one does.
Repeat calls hit the documented cache and come back in milliseconds with x-cache: hit, charged the same as a fresh call. Add fresh=true on the first read of a monitoring pass to bypass it. Calls that fail, on a private or deleted post, are never charged.
The short version
Threads has no public read API from Meta, on purpose. The official API publishes and manages your own account, and stops there. To read public Threads data you use a third-party API that reads logged-out pages and returns profiles, posts, stats, and search as JSON, minus the view counts Threads never makes public. Pick Meta’s API to post; pick a read API to listen.
Frequently asked questions
Does Threads have a public API?
Not in the way most people mean. Meta’s official Threads API, launched June 2024, lets you publish posts and read your own account’s content and insights. It cannot read arbitrary public profiles, posts, or stats from accounts you don’t own. To pull public Threads data at scale you need a third-party read API that reads the public web, not Meta’s publishing API.
How do I get a Threads API key?
For the official API you register a Meta app, add the Threads use case, request scopes like threads_content_publish, and pass Meta’s app review, after which users authorize your app with OAuth. That key only touches accounts that authorize you. For reading public Threads data you skip all of it and use a data API key that reads public pages logged out.
Can I scrape Threads without the official API?
Yes, by reading the same public pages a logged-out visitor sees. A Threads data API takes a handle or post URL and returns the public profile, posts, or engagement counts as JSON, with no Meta app, no OAuth, and no ownership of the account. It cannot see anything private, and it cannot see view counts, because those are not on the public page.
Why can’t I see Threads view counts?
Threads shows view counts only to the post’s author, inside the app’s own insights. They are not printed on the public post page, so a logged-out reader cannot see them and neither can any public data API. Likes, replies, reposts, and quotes are public and are returned; views are not, and anyone offering public Threads view counts is either the account owner or estimating.
Can the official Threads API read other people’s posts?
Only in narrow, gated ways. You can read content from accounts that authorize your app, and there is a keyword-search capability behind Meta app review with its own rate caps. There is no endpoint to freely pull any public profile, its post history, or a specific post’s stats. That gap is the reason competitor tracking and agency reporting use third-party read APIs.
Is the Threads API free?
The official Meta Threads API is free, with no paid tier or per-call fee, but it is rate-limited per profile: about 250 posts, 1,000 replies, and 100 deletions in any rolling 24 hours. It is a publishing tool, so those limits are shaped around posting, not reading. A third-party read API charges per item returned instead, because it is doing the public-web reading Meta’s API does not.
Pull one public post
Start with a single post you can already see in a browser. Send its URL to the Threads stats endpoint, read the counters back as JSON, and confirm there is no views field before you design around one. The full Threads API covers profiles, posts, and search too, and 100 free credits are enough to pull a real account end to end.