Works with your stack
cURL Python Node.js 
MCP
One key · one credit balance · plain REST MCP One handle in. Clean JSON out.
Give this endpoint a Threads handle and it returns that account's public profile as JSON: display name, bio, follower count, verification flag, avatar and bio link. It reads the same page anyone can open logged out, so there is no OAuth step and no Meta app review. One GET to /v1/threads/profile, 4 credits.
MCP The difference
On the left, what a headless browser hands you. On the right, what the endpoint hands you.
<div class="x1a2b3c x9k2m1 xdt5ytf" data-pressable-container="true"><div class="x78zum5 xdt5ytf"><div class="x9f619 x1n2onr6"><span class="x1lliihq x1plvlek"><span dir="auto" class="x1lliihq xjkvuk6">Everyone building ai agents keeps rediscovering the same three problems.</span></span></div><div class="x6s0dn4 x78zum5 xl56j7k"><div role="button" tabindex="0" class="x1i10hfl x1qjc9v5"><svg aria-label="Like" role="img" viewBox="0 0 24 24"><path d="M16.792 3.904..."></path></svg><span class="x17qophe">88.4K</span></div><div role="button" tabindex="0" class="x1i10hfl"><svg aria-label="Reply"></svg><span>2,314</span></div></div><time datetime="2026-07-07T09:40:00.000Z" class="x1rg5ohu">2h</time></div><script>requireLazy(["ServerJS"],function(f){f().handle({"__bbox":{"complete":true,"require":[["ScheduledServerJS"... {"data": {"platform": "threads","handle": "zuck","name": "Example Creator","bio": "Notes on building in public. Links in profile.","verified": true,"metrics": {"followers": 2450318}},"request_id": "req_01JZX4M8Q2TE9W"}
The payload
One object per handle. It is a header-card scrape: who the account says it is, how many people follow it, whether Meta has verified it, and where the bio points. That covers the fields most people actually store in a creator database — enough to dedupe accounts, rank a shortlist by audience size, and follow the outbound link to a website or Linktree.
What it does not carry is a posting history. There is no post count, no following count, no engagement figure, no join date. Threads exposes far less on a profile than Instagram or X do, and we return what is there rather than padding the shape with keys that would always be null. If you need activity, the Threads Posts API is the second call.
Follower counts are point-in-time. Threads rounds them in the UI once an account gets large, so a figure you read here is the platform's public number at call time, not an exact roster size. It is fine for ranking and tiering, less fine for anything that needs to be accurate to the person.
Public follower count. Rounded by the platform on large accounts; null if Threads is not showing a count.
Pricing
One profile is 4 credits — about 2¢ on the monthly plan, 1.8¢ annual — so $5 covers roughly 250 handles, and calls that error on a private or missing account are never charged.
Estimate only, on a full-year basis. 4 credits per returned profile. Monthly: $5 per 1,000 credits with $4/1,000 top-ups. Annual: $54 per 12,000 credits with $3/1,000 top-ups. We show whichever plan is cheaper for your annual volume, divided by 12. Failed calls are never charged; cache hits cost the same as fresh calls.
Entry price, side by side
Credits are not equivalent units across vendors — each meters differently. Price your own workload on both before deciding on entry price alone. At high volume, several of these are cheaper per credit than we are.
Engineering notes
We document exactly how every endpoint behaves — nulls, caching, billing — so what you ship on day one is still running in month six. No surprises, no support tickets.
If you have built against an Instagram or X profile endpoint before, budget for a smaller object. Threads publishes eight useful things on a public profile and that is the whole list. Anything shaped like activity — posts made, replies, accounts followed — is absent from the source, not stripped by us.
The practical consequence: you cannot compute an engagement rate from this endpoint alone. You need a post sample, which means a second call to the Threads Posts API and a divide.
avatar_url points at Meta's CDN with a signed query string. It works when you receive it and stops working some hours later. Storing the string in a database and rendering it in a dashboard next week will give you broken images. Download the bytes at fetch time and put them in your own storage.
A Threads user can rename themselves and the old handle becomes available for someone else to claim. If you key a table on handle you will eventually merge two unrelated people. Key on id, keep handle as a mutable attribute, and re-resolve handles you have not seen in a while.
Private accounts return an error, not a partial profile. So do handles that never existed and accounts that have been deleted or suspended. We read logged out; if the page does not render for an anonymous visitor it does not render for us either. Errors are not billed.
Names, bios and avatars of real people are personal data under GDPR and similar regimes even though they are public. If you store them, know your lawful basis, keep a retention window, and be able to delete on request. Refreshing a profile you already hold is also the cheapest way to keep it accurate — stale records are their own compliance problem.
Profiles change slowly, so responses sit in the slow cache class. Repeat calls for the same handle inside the window come back in milliseconds and set x-cache: hit. A hit costs the same 4 credits. Pass fresh=true when you need to force a re-fetch, for instance the morning a growth job runs.
Questions
Call GET /v1/threads/profile with the handle and your API key. The response includes followers as a number alongside name, bio, verification and the bio link. Meta's own Threads API only reaches accounts that have authorised your app, so it cannot read a competitor or a creator you are evaluating. This endpoint reads the public profile page instead, with no OAuth.
4 credits per handle. At $0.005 per credit on the monthly plan that is 2 cents a profile, or about 250 profiles for $5; annual credits are $0.0045 each. Cached responses cost the same as fresh ones, and calls that error — private account, wrong handle, deleted user — are not charged at all.
No. This is a profile-only call and returns no posts, no post count and no engagement figures. Threads does not publish those on the profile page. If you need the posts, call the Threads Posts API with the same handle; it returns a single batch of up to limit posts — there is no cursor to page beyond that — and costs per post returned rather than per profile.
The input is the bare handle, so strip it out of the URL first. From https://www.threads.com/@somebody you want somebody. The leading @ is tolerated. Anything else in the path — a post id, a query string — should be removed before you call, or the lookup will fail against a handle that does not exist.
It is the number Threads displays publicly, which the platform rounds once an account gets large and updates on its own delay. Good enough to sort a list, tier creators, or watch a trend over weeks. Not good enough if you need an exact figure for a contract. Sample on a fixed daily cadence if you are charting growth, so your intervals stay even.
No to both. Private profiles return an error, and we never expose contact details that Threads does not publish — there is no email or phone field in the response. The only outbound contact route here is link, the first URL in the bio, which the account holder chose to publish. We read public pages logged out and nothing else.
One handle per call — there is no batch input, so a thousand handles is a thousand calls. Issue them concurrently and back off on any rate-limit response rather than assuming a fixed safe concurrency; we do not promise a specific number of parallel calls or a wall-clock figure. Deduplicate your handle list first — the slow cache means repeats are fast, but they still cost 4 credits each, so paying twice for the same account is avoidable.
Next
100 trial credits on signup — no card, key on screen immediately.