Meta Threads API: What It Does, Its Limits, and Where Twitter (X) Data Still Comes From

Meta's overview states the purpose in one sentence: the Threads API lets apps "create and publish content on a person's behalf on Threads, and to display those posts within your app solely to the person who created it." That framing matters. The core of the API is a first-party, user-authorized API: a Threads user signs in to your app, grants permissions, and your app acts for that user and reads that user's data. Public discovery features (keyword search, profile discovery, mentions from other users) were added later and each one sits behind its own permission and App Review.

Hosts and versioning. Calls go to graph.threads.com or graph.threads.net, with a version segment such as /v1.0/. The shape will feel familiar to anyone who has used Meta's Graph API: node IDs in the path, a fields parameter to choose the response fields, and an access_token parameter.

What you can build with it. A scheduler or social media manager that publishes to Threads; a reply-management inbox for a brand's Threads account; an analytics view of a creator's own Threads performance; a search feature over public Threads posts once approved; and a profile lookup of public accounts with at least 100 followers.

What it is not. It is not a firehose and has no streaming endpoint in the pages we read; reply and mention webhooks exist for the authorized user's account. It returns no data about X, Instagram feeds or Facebook. And the Threads docs pages we read publish quotas, not a per-call price list: cost is your engineering time and App Review, while volume is governed by the limits below.

Meta's get-started guide asks you to create an app and pick the Threads use case. Creating the app yields two app IDs and secrets; for the Threads API you use the Threads app ID and its secret. Users then authorize your app through the Authorization Window, which returns an authorization code that you exchange for a token.

Tokens. Short-lived user tokens are valid for 1 hour. Exchange them for long-lived tokens, valid for 60 days, and refresh those before they expire with GET /refresh_access_token. Permission grants from users with public profiles last 90 days and are extended when you refresh; for private profiles the grant cannot be extended and the user has to grant it again.

App Review is the real gate. Threads testers on your app can grant any permission at any time. For everyone else, "each permission must first be approved through the App Review process, and your app must be published." Until then, publishing only works for testers, keyword search only finds the token owner's posts, and mentions only return mentions made by testers. Plan for review time before you promise a launch date.

Media hosting. Meta downloads any image or video you publish from a public URL at the time of the attempt, so your media must sit on a publicly reachable server.

Meta documents two layers of limits: an app-level call budget per app-and-user pair, and per-profile quotas on specific actions. All of these are rolling 24-hour windows.

How the call budget works. "Calls within 24 hours = 4800 * Number of Impressions", where impressions are the number of times content from the user's Threads account entered someone's screen in the last 24 hours, with a minimum of 10. A brand-new account with almost no reach therefore still gets 4,800 x 10 = 48,000 calls a day. Meta adds CPU-time ceilings of 720,000 x impressions for total CPU time and 2,880,000 x impressions for total time.

Reading your quota. GET /{threads-user-id}/threads_publishing_limit returns quota_usage and a config object with quota_total and quota_duration (86,400 seconds). Ask for reply_quota_usage, delete_quota_usage or location_search_quota_usage to see the other quotas. Meta tells schedulers to enforce the publishing limit themselves, especially when users can queue posts for later.

Search quota quirks. The 2,200-query limit follows the user, not the app: two apps searching for the same user share it. Repeating the same keyword still counts. Queries that return nothing do not count, and keywords Meta deems sensitive or offensive return an empty array rather than an error.

Publishing a single text, image or video post is two calls. First POST /{threads-user-id}/threads creates a media container (media_type of TEXT, IMAGE or VIDEO, plus text, image_url or video_url). Then POST /{threads-user-id}/threads_publish with the container's creation_id publishes it. Carousels add child containers first. Text posts are limited to 500 characters, and Meta counts emojis by their UTF-8 bytes.

Meta's posts guide also covers topic tags, link attachments, GIFs, polls, spoilers, quote posts, reposts and labeling AI-generated content. Replies use the same container pattern with a reply target and the reply permissions.

On X, for comparison. The official X API's rate card prices a created post at $0.015, or $0.200 when the post contains a URL. TwitterAPI.io offers writes through an authenticated session: one /twitter/user_login_v2 login ($0.10, with a proxy you supply) returns login_cookies, and each write after that (a post through /twitter/create_tweet_v2, or a like, retweet, follow or delete) is 60 credits, $0.0006, billed per HTTP 200 call. The call acts as that account, so X can rate-limit, lock or suspend it; keep a human pace, and expect the session to need a fresh login from time to time.

Search is the feature most builders mean when they type "threads api keyword search". The endpoint is GET /keyword_search and it searches public Threads media by keyword or by topic tag.

Fields. Results use the media fields from the retrieval docs (id, text, media_type, permalink, timestamp, username, has_replies, is_quote_post, is_reply and more); the owner field is excluded from search results.

Coverage is the catch. Without approval for threads_keyword_search the search runs only over posts owned by the authenticated user. After approval, public posts are searchable, but private profiles never are, sensitive keywords come back empty, and the per-user budget is 2,200 queries a day. For a brand monitoring tool that is generous for a dashboard and tight for a background poller: a single keyword polled every minute is 1,440 queries a day on its own.

On X, the equivalent is search over public posts. With TwitterAPI.io, /twitter/tweet/advanced_search takes X's search operators (from:, since:, -is:retweet, lang:) and returns 20 tweets per full page at $0.15 per 1,000 tweets; an empty check costs the $0.00015 minimum, so polling one query every 60 seconds for a month has a floor of $6.48.

Profile discovery. GET /profile_lookup?username=... returns basic public profile information (including follower_count), and GET /profile_posts?username=... pages through that profile's posts. Both need threads_profile_discovery, both are limited to 1,000 requests per user per 24 hours, and both only return public profiles with at least 100 followers. Meta's changelog notes that threshold was lowered from 1,000 followers to 100.

Mentions. The mentions endpoint returns public posts in which another profile tagged the authorized user. It needs threads_manage_mentions; before approval it only returns mentions made by your app's Threads testers, and posts by private users are never returned. It is a mentions inbox for your own user, not a way to watch mentions of an arbitrary brand.

Insights. GET /{threads-media-id}/insights returns views, likes, replies, reposts, quotes and shares for a post (Meta marks views and shares as metrics in development), and GET /{threads-user-id}/threads_insights returns account-level metrics. These are for the user's own Threads only; the since and until filters reject anything before Unix time 1712991600 (April 13, 2024).

On X, the same three needs map to public endpoints with no user authorization: /twitter/user/info for a profile ($0.18 per 1,000 profiles), /twitter/user/mentions for posts mentioning any account (20 per page), and public counters on every tweet (likeCount, retweetCount, replyCount, quoteCount, viewCount, bookmarkCount). Private account analytics on X still require the official API with the account owner's consent.

The three are not substitutes; they cover different networks and different trust models. The Threads API is user-authorized access to Threads. The official X API is X's own metered API. TwitterAPI.io is a third-party API for public X data plus session-based X actions.

Pricing context for X. X's rate card (docs.x.com/x-api/getting-started/pricing) lists $0.005 per post read, $0.010 per user read and $0.010 per follower or following read, with pay-per-usage capped at 3 million post reads a month (Enterprise above). New paying developers get $20 in credits after a first card and credit purchase, plus a match of the first auto-recharge up to $50. Against TwitterAPI.io's $0.15 per 1,000 tweets, X's $5 per 1,000 post reads is about 33x more for the same tweets.

A naming trap. If you look for Threads on X, the handle @threads is not Meta: its bio reads "Threads is a Slack replacement designed for makers" and says it has no affiliation with Meta. We excluded it from the study for that reason. Always confirm the account by ID before you build a feed around it.

To test whether a Threads-only listener would see Meta's X conversation, we pulled the latest X timelines of five Meta accounts through /twitter/user/last_tweets: 499 posts, 339 of them original (not reposts), collected in 2026.

Zero links to Threads. Of 339 original posts, 0 linked to threads.com or threads.net, 1 linked to instagram.com, 45 linked to other Meta-owned sites (about.fb.com, go.meta.me, meta.ai), 54 used bit.ly short links (almost all from @MetaforDevs, destinations not resolved), 15 linked elsewhere and 224 carried no link. Only 1 post in the sample even named Threads in its text.

Reach is real on X. @instagram's original posts had a median of 694,453 views; @AIatMeta's 149,600; @Meta's 145,244. @MetaforDevs, the developer account that announces Threads API changes, posted the most often, 7.42 times a week, with the highest median engagement rate (0.969% of views).

What this means for builders. Even the company that owns Threads runs its X presence as its own channel: the posts, the replies and the audience reaction live on X. A listening or analytics product that only connects the Threads API sees none of it; X data has to come from an X data source.

Question. Do Meta's own accounts on X point their audience to Threads, and how much reach do their X posts get?

Accounts. @Meta, @mosseri (Adam Mosseri, whose X bio describes him as head of Instagram), @MetaforDevs, @instagram and @AIatMeta: organization and public-figure accounts. @threads was screened out (an unrelated company) and @zuck returned "user not found".

Window and sample. The most recent posts per account at collection time, up to 120 each (6 pages of 20), 499 posts in total, collected in 2026. @mosseri posts rarely, so his 19 posts span years; @MetaforDevs' 120 span about 113 days.

Cost. 33 requests, 499 tweets returned; at $0.15 per 1,000 tweets plus $0.18 per 1,000 profiles the study cost about $0.08.

What the sample cannot show. Timelines without replies (the default), so reply traffic is not counted. Short links were not expanded, so a bit.ly link could still lead to Threads. Five accounts are not all of Meta. And this says nothing about how these accounts perform on Threads itself, which only their owners can read through Threads insights.

Privacy. Aggregates only; organization and public-figure accounts only; reposted and quoted authors were not analyzed. The data and scripts live in data/studies/threads-api/.

Building with both. A practical stack for a cross-network product: the Threads API for the Threads side (publishing for your users, their insights, approved keyword search), and an X data API for the X side. To try the X half, create a key on the dashboard: new accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days), which covers about 6,600 tweets at $0.15 per 1,000. Rate limits are 0.2 requests per second before the first payment and 20 after; the full reference is at docs.twitterapi.io.