Threads API in Python: What the Official API Reads, and How to Get Public Posts and Replies

The official Meta Threads API is mainly for accounts that manage their own content. If your app is not approved, keyword search finds only your own posts. To read other people's profiles and posts, you need Advanced Access. The official post object also has no like count or reply count fields.

We used Python to call the EveryInfra Threads capabilities at three times (Singapore time, SGT). The times were 22:31 and 23:00 on November 13, 2026, and 00:24 on November 14, 2026. Each time, we ran the chain "search, then post, then replies, then author profile".

In round 3, the full script made 4 calls, cost $0.002446 and returned 82 rows, which is $0.0298 per 1,000 rows. A search for "threads api" returned 50 posts, and none of them was about the Threads API. A second search half an hour later returned 50 different posts. Thus, search many times, remove duplicates and then filter on the text.

Key points

• Without approval for threads_keyword_search, the official keyword search finds only your own posts. After approval, each user gets 2,200 searches per 24 hours. Lookups of other people's profiles and posts work only for public accounts with 100 or more followers, 1,000 per day, and they need Advanced Access. A business app must first become a Tech Provider, and you cannot undo that change.
• The official post object has 27 fields (with id), and none of them is a like, reply or view count. These counts are in insights, and insights read only the posts of the account that gave access.
• In our test, threads/search returned up to 50 posts per call for $0.000778. The searches at 22:31 and 23:00 had 0 posts in common, and 8 searches gave 224 different posts. We checked the 50 posts from 22:31 one by one by hand, and 0 of them were about the Threads API.
• To read replies, send the link from search to threads/comments as it is. To read post details, use the full post link. With this method, the replies call in the round 3 script returned 30 replies, each with reply_to and author_name.
• A call that returns 503 is free. Wait for the retry_after seconds in the response, and then the retry gives a result.

Three routes: the official Threads API, your own Threads scraper, or a third-party data API

In November 2026, you have three routes to read public Threads posts and replies with code. EveryInfra prices come from the public catalog on November 13, 2026. The charge for each call is the charged_usd value in the live response.

Route	What it reads (checked in the official docs, open-source repositories or our live calls)	What you need	Cost	What to know
Official Threads API	Your own posts, replies and insights. After review: keyword search on public posts, and lookups of public accounts with 100 or more followers	A Meta developer app and OAuth user tokens. Advanced Access to read other people; a business app must first become a Tech Provider	No charge per call; 4,800 × impressions calls per 24 hours	Without approval, keyword search finds only your own posts. The post object has no like count or reply count fields
Your own scraper	The content that the web page shows to the public	You maintain the requests, the parser and the network exits	The code is free; proxies and maintenance time are extra	Each layout change breaks your code
Third-party data API (EveryInfra in this article)	Public post search, account posts, post details, public replies, profiles, profile discovery	One API key; no login to any Threads account	Search $0.000778 per call, other capabilities $0.000556 per call; failures and empty results are free	Returns only content that the public can see
All three routes	Threads Terms of Use 3(a)(iv) and Meta Terms of Service 3.2 limit automated collection, and robots.txt says Disallow: / to crawlers that it does not name	Check the terms and the laws where you are before you start	—	The quotes are in the "Meta's terms" section below

Only the official API can manage your own brand account, publish posts and show the views on your own posts. To read other people's public posts and replies, the official route needs a permission review first. A third-party data API needs one key, and the documents in the last row of the table apply to it too.

What the Threads API can read: the official docs, line by line

Meta describes the purpose of the Threads API in one sentence. The 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" (Threads API overview, updated December 22, 2025). The read side follows the same idea. You read your own posts with GET /me/threads, the replies to your own posts with GET /{media-id}/replies, and your own numbers with the insights endpoints. On November 13, 2026, we opened each page in the docs that is about reading data. Each cell in the table below comes from a sentence on those pages.

What you want to read	Official endpoint	Permission	What you get without Advanced Access	Limit
Posts from your own account	GET /{user-id}/threads	threads_basic	Only the account that gave you a token	App call count: 4,800 × impressions per 24 hours
Posts from any public account	GET /profile_posts?username=	threads_basic + threads_profile_discovery	Only some official Meta accounts; the docs name @meta, @threads, @instagram and @facebook	1,000 requests per user per 24 hours; public profiles with 100+ followers only
A public profile	GET /profile_lookup?username=	Same as above	Same as above	Same as above
Posts that match a keyword or a topic tag	GET /keyword_search	threads_basic + threads_keyword_search	Only your own posts	2,200 queries per user per 24 hours, across all apps
One post by ID	GET /{media-id}	threads_basic	Only posts from a Threads tester	App call count
Replies under a post	GET /{media-id}/replies, /conversation	threads_basic + threads_read_replies	Replies on posts that you manage	App call count
Posts that mention you	GET /{user-id}/mentions	threads_manage_mentions	Only mentions from testers	App call count
Trending topics and their posts	GET /trending_topics, /{trend-id}/posts	App token + the Trending Topics feature	Topic list only; posts need Advanced Access; USA and Japan only	Topics change at most once per hour

The first three rows come from Retrieve user posts (updated April 14, 2026) and Threads profiles. The search row comes from Keyword and topic tag search (updated January 21, 2026). The last rows come from Retrieve media replies and conversations, Mentions and Trending topics. The call-count formula is on the overview page: "Calls within 24 hours = 4800 * Number of Impressions".

Meta counts at least 10 impressions, so even a new account gets at least 48,000 calls per day. To read content from other people, you must first pass a permission review.

The table shows one pattern. Each way to read data from other people has its own permission. Without Advanced Access, that permission works only for you, your testers, or a few Meta accounts. The Access Levels page (updated June 30, 2026) says that Standard Access works only for people who have a role on your app.

Advanced Access needs Business Verification, and some permissions also need App Review. So the answer to "can the Threads API read other people's posts" depends on Advanced Access for each permission. The docs do not show a path for a solo developer who wants to read public posts at scale.

The permalink field is not returned when a post contains copyrighted material, and the owner field appears only on your own top-level posts. Profile lookup and the public post list return only public profiles with at least 100 followers. Meta lowered that limit from 1,000 to 100 on November 20, 2025 (Threads changelog). The official path cannot see accounts with fewer than 100 followers.

Threads API keyword search: before approval, it only searches your own posts

Google suggestions for "threads api" include "threads api keyword search" and "threads api search" (read on November 13, 2026). The docs give the rule in two sentences: "If your app has not been approved for the threads_keyword_search permission, the search is performed only on posts owned by the authenticated user" and "After approval, public posts are searchable". If your app is not approved, /keyword_search returns only posts from your own account.

Two key limits of official keyword search: 2,200 queries per user per day, and only your own posts before approval screenshot of the Meta for Developers page Keyword and topic tag search, read November 13, 2026

Several developers tested this and posted the results on the Meta developer forum. In Threads keyword_search returns only my own posts, one developer sent q=tarot, search_type=RECENT and limit=100. The API returned HTTP 200 with 100 posts, and all 100 came from the developer's own account. Another post logs six searches at 00:38 Japan time on October 21, 2026, with three common Japanese words.

All six returned an empty array. The same token could read the owner's profile and posts. The dashboard showed threads_keyword_search as "Ready for testing", not as approved. In a third post, the after cursor returned the same single post and the same cursor again.

To search public posts, your app must pass App Review. The forum posts describe the same block. When you click "Add to App Review", the dashboard asks the business to become a Tech Provider. It also warns that you cannot reverse this choice (first-party brand app question, internal business app question). Meta's Tech Providers page defines a Tech Provider as a business that needs "to access business data owned by other businesses in order to provide services or functionality to those businesses".

The same page lists seven Threads permissions. A business app can get them only as a Tech Provider, or for users with a role on the app. The list includes threads_basic, threads_keyword_search and threads_read_replies. A brand team that serves only itself must either become a Tech Provider or use the app only with people who have app roles. As of November 13, 2026, no Meta employee had posted a different path in the threads we read.

After approval, the limit is 2,200 queries per user in a rolling 24-hour window. A repeat query for the same keyword counts again. A query with no results does not count. Keywords that Threads marks as sensitive or offensive always return an empty array. The parameters are: search_type (TOP or RECENT), search_mode=TAG for topic tags, media_type for text, image or video posts, and since and until.

The earliest since value is 1688540400, which is July 5, 2023. The default limit is 25 and the maximum is 100. Since January 20, 2026, author_username filters the results to one account. The owner field is never returned.

Fields in a Threads post: official API and pay-per-call API

The post object in the official Threads API has no like count, reply count or view count. The Retrieve user posts page lists 27 media fields (with id, which is returned by default), from id, text and timestamp to poll_attachment and ghost_post_status. None of them is a count.

The sample request on the keyword search page asks only for id,text,media_type,permalink,timestamp,username,has_replies,is_quote_post,is_reply. The counts are on a different endpoint, /{threads-media-id}/insights. The first line of the Insights docs says that it reads insights from "users' own Threads posts and profiles". That is, it reads only the posts of the account that gave you access, and it needs the threads_manage_insights permission.

Thus, Advanced Access for keyword search and profile discovery is not sufficient. With the official API, you cannot sort other people's posts by likes or replies. You see the text, the time, and whether a post has replies (has_replies). The only official place where you see activity on another account is profile_lookup. It gives the total likes, quotes, reposts and views for all posts of a public account in the last 7 days. That is an account total, not a number per post (Threads profiles).

What you want	Official Threads API	EveryInfra Threads capabilities (response_fields in the catalog)
Post ID, text, time, link	id, text, timestamp, permalink (omitted for copyrighted content)	id, text, posted_at, url
Author	username; owner only on your own top-level posts	author_username, author_name, author_id, author_is_verified
Likes and replies on other people's posts	No field; insights read only your own posts	like_count, comment_count (search, user_posts, post_detail)
Views, reposts, quotes, shares	Only in insights for your own posts	view_count, repost_count, quote_count, share_count (the catalog lists them for user_posts and post_detail)
Reply tree	has_replies, root_post, replied_to, is_reply, hide_status	reply_to, author_name; the catalog does not say if nested replies come back, and we did not test this separately
Topics, mentions, links	topic_tag, link_attachment_url	hashtags, mentions, links
Profile	profile_lookup: followers and 7-day activity totals	threads/profile: follower_count, bio, is_private, external_url
Paid partnership label	Not in the docs	is_paid_partnership (post_detail)

The right column comes from the EveryInfra public catalog, read at 21:30 Singapore time (SGT) on November 13, 2026. Each capability has its own response_fields list, and the table shows only field names that appear there. Both sides have the ID, the text, the time and the author. The differences are in the counts and in the reply structure.

The official reply fields are more complete: they separate direct replies from nested replies, and they show the hidden status. The pay-per-call API can read counts on other people's posts. To sort other people's posts by reply count, you need an API that has count fields.

The Threads API changelog: 20 of 89 entries are for reading, and each added a new permission

Will the official read features open up soon? To estimate this, we labeled all 89 entries in the Threads Changelog. The earliest entry is from April 8, 2024, before the API opened to all developers on June 18, 2024. We labeled all entries up to November 13, 2026. The labels are: read and discovery (search, profiles, reading replies, new fields on read endpoints), publish and reply, insights and webhooks, ads, and tokens and other. Each bullet under a date counts once, and we labeled each one by hand from its title and first sentence.

Type	Entries	First entry	Latest entry	Last 12 months (2025-11-13 to 2026-11-13)
Publishing (posts, replies, quotes, reposts, formats)	31	2024-05-02	2026-03-25	9
Reading (retrieval, search, mentions, profiles, reply reads, new read fields)	20	2024-04-18	2026-03-03	4
Other (tokens, domains, docs, debugging)	16	2024-04-08	2026-08-18	2
Insights and webhooks	14	2024-04-26	2026-01-30	2
Threads ads	8	2025-08-15	2026-04-21	4
Total	89	—	—	21

These read entries had the largest effect. On December 9, 2024, Meta added keyword search and the mentions list. On July 14, 2025, it added profile and post lookup by username, topic tag search and time filters. On November 20, 2025, it lowered the follower limit for profile discovery from 1,000 to 100.

On January 20, 2026, it added author_username to keyword search. The last read entry is from March 3, 2026: the oEmbed API no longer needs an access token. After August 18, 2026, the changelog has no new entries at all. On November 13, 2026, that is almost three months.

Read is the second-largest group. It has fewer entries than publishing (31) and more than insights (14) and ads (8). Read features for other people's content do grow, but each one comes with a new permission and a new review. From March 3, 2026, to November 13, 2026, no new read feature was added in 8 months. We put the reply approval entry in the publishing group.

Threads API Python test: one chain at three times

We called the EveryInfra Threads capabilities at three times (Singapore time, SGT). Round 1 ran from 22:31 to 22:46 on November 13, 2026, and round 2 ran from 23:00 to 23:07. Round 3 ran from 00:24 to 00:31 on November 14, 2026. Each round used the same chain. First, threads/search searched the keyword "threads api".

Then the chain took the post with the most replies and read its details with threads/post_detail. Next, it read the replies with threads/comments and the author profile with threads/profile. To see how one post changes over time, each round also read the details of two news posts. One is a post by The New York Times (@nytimes) on November 12 about a Microsoft service outage. The other is a post by BBC Chinese (@bbcchinese) on November 11 about a UK civil servant who held five jobs.

This is the full script. It needs only requests, and it reads the key from an environment variable. We ran this English version from 00:31:25 SGT on November 14, 2026. Its real output is below the code.

"""One chain of public Threads data: keyword search -> post details -> replies -> author profile.
Usage: EVERYINFRA_API_KEY=... python3 threads_chain.py "keyword" [output_dir]
Needs only requests; the key comes only from the environment."""
import csv, json, os, sys, time
import requests

API = "https://api.everyinfra.com/api/v1/social"
KEY = os.environ["EVERYINFRA_API_KEY"]
S = requests.Session()
S.headers.update({"Authorization": f"Bearer {KEY}", "Content-Type": "application/json"})
spent = 0.0


def call(action, **params):
    """Call threads/<action> once; up to three tries; wait 60 s after a 429 and retry_after seconds after a retryable 503."""
    global spent
    for _ in range(3):
        r = S.post(API, json={"platform": "threads", "action": action, "params": params}, timeout=180)
        body = r.json()
        if r.status_code == 429:
            time.sleep(60); continue
        if r.status_code == 503 and body.get("error", {}).get("retryable"):
            time.sleep(min(body["error"].get("retry_after", 60), 300)); continue
        break
    spent += (body.get("billing") or {}).get("charged_usd") or 0
    if r.status_code != 200:
        raise RuntimeError(f"threads/{action} {r.status_code}: {body.get('error', {}).get('message')}")
    return body


def full_link(post):
    """Full post link https://www.threads.com/@username/post/<code>, for post details."""
    code = post["url"].rstrip("/").split("/")[-1]
    return f"https://www.threads.com/@{post['author_username']}/post/{code}"


def main(keyword, out="."):
    posts = call("search", keyword=keyword, limit=50)["results"]
    print(f"search: {len(posts)} posts")
    top = max(posts, key=lambda p: p.get("comment_count") or 0)   # the post with the most replies
    detail = call("post_detail", url=full_link(top))["results"]
    detail = detail[0] if isinstance(detail, list) else detail
    replies = call("comments", url=top["url"])["results"]   # short link as it is
    author = call("profile", username=top["author_username"])["results"]
    author = author[0] if isinstance(author, list) else author
    print(f"post_detail: like={detail.get('like_count')} reply={detail.get('comment_count')}")
    print(f"comments: {len(replies)} replies; profile: follower_count={author.get('follower_count')}")
    with open(os.path.join(out, "posts.csv"), "w", newline="", encoding="utf-8") as f:
        w = csv.DictWriter(f, ["id", "url", "posted_at", "like_count", "comment_count", "author_username", "text"], extrasaction="ignore")
        w.writeheader(); w.writerows(posts)
    with open(os.path.join(out, "replies.csv"), "w", newline="", encoding="utf-8") as f:
        w = csv.DictWriter(f, ["id", "posted_at", "like_count", "comment_count", "reply_to", "author_name", "text"], extrasaction="ignore")
        w.writeheader(); w.writerows(replies)
    rows = len(posts) + 1 + len(replies) + 1
    print(f"total {rows} rows, spent ${spent:.6f}, ${spent / rows * 1000:.4f} per 1,000 rows")


if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2] if len(sys.argv) > 2 else ".")

search: 50 posts
post_detail: like=10315 reply=799
comments: 30 replies; profile: follower_count=112
total 82 rows, spent $0.002446, $0.0298 per 1,000 rows

Search returned 50 posts. The post with the most replies had 799 replies and 10,315 likes in the details call. The replies call returned 30 replies, and each reply had reply_to and author_name. The author profile had 112 followers. The four calls cost $0.002446 in total (search $0.000778, and $0.000556 for each of the other three). For 82 rows, that is $0.0298 per 1,000 rows.

Round (SGT)	Search returned	Posts that earlier searches also returned	NYT post: likes / replies	BBC Chinese post: likes / replies	Charge for the round
Round 1, Nov 13, 22:31 to 22:46	50	47 between 22:31:06 and 22:31:40	216 / 18	864 / 35	$0.009340
Round 2, Nov 13, 23:00 to 23:07 (without the 23:05 script run)	50	0 (compared with the two 22:31 searches)	215 / 19	864 / 35	$0.007116
Round 3, Nov 14, 00:24 to 00:31 (search, two news posts, script)	44	0 (compared with the five searches on Nov 13)	216 / 19	864 / 35	$0.005448

The counts on the two news posts almost did not change. The NYT post went from 18 to 19 replies, and its likes stayed at 215 or 216. The BBC Chinese post had 864 likes and 35 replies all three times. These two posts were one or two days old, and their counts stayed almost the same for two hours.

In round 3, we read the replies of these two posts with the method below. The NYT post returned 17 replies, and all 17 replied to the post. The BBC Chinese post returned 28 replies: 22 replied to the post and 6 replied to other users. The four news calls in this round took 6.7 to 25.2 seconds each. The two details calls took less than 8 seconds, and the two replies calls took more than 20 seconds.

The same post came back again in the second script run (from 00:31:25). Its search row went from 10,298 likes and 797 replies to 10,311 likes and 799 replies. The details call gave 10,315 likes and 799 replies. The counts on a busy post change all the time, so store the read time and the counts in the same row.

The author of this post had 112 followers. The post that the 23:05 run selected on November 13 (1,838 replies) came from an account with 7 followers. In these two samples, small accounts had single posts with hundreds or thousands of replies. If you filter accounts by follower count, you can miss posts like these. In this round, 26 of the 50 search results had 0 replies, and the top three reply counts were 797, 763 and 173.

Which link to send to each capability

We recommend this method. To read replies, send the post link from search (https://threads.com/t/<code>) to threads/comments as it is. To read post details, use the full post link https://www.threads.com/@username/post/<code>. The catalog uses this format for the post_detail parameter. The full_link() function in the script makes the full link from author_username and the code, and the script uses it only for details.

From 00:24 to 00:27 SGT on November 14, 2026, we used this method to read the replies to one post each from three news accounts. The posts were from The New York Times on November 11, BBC Chinese on November 12 and CNN en Español on November 13. The calls returned 30, 30 and 9 replies. Each reply had reply_to (the account that the reply answers) and author_name.

The reply_to field shows the reply levels. On the NYT post, 28 of the 30 replies answered @nytimes, and 2 answered other users. On the BBC Chinese post, 25 of the 30 answered @bbcchinese, and 5 answered other users. Thus, the results contain direct replies and also some replies to replies. To separate the two groups, compare reply_to with the post author.

Post (Nov 14, 2026, SGT)	Replies returned	reply_to = post author	reply_to = other user
The New York Times, Nov 11 (00:24)	30	28	2
BBC Chinese, Nov 12 (00:25)	30	25	5
CNN en Español, Nov 13 (00:27)	9	9	0
The New York Times, Nov 12 (00:28, round 3)	17	17	0
BBC Chinese, Nov 11 (00:29, round 3)	28	22	6

Search results change between calls

There is no page cursor, and the same keyword gives very different posts each time. threads/search has only one parameter, keyword, and limit is 50 at most. The catalog also says that search cannot filter by date.

We searched twice, at 22:31:06 and 22:31:40, and 47 posts were the same. The search at 23:00 had no post in common with the two 22:31 searches. The 23:05 script run and the 23:00 search had 11 posts in common. On November 14, the search at 00:24 returned 44 posts, and none of them was in the five searches of the previous night.

The overlap depends on the time between two searches. The searches at 00:29:59 and 00:31:25 on November 14 were one and a half minutes apart, and 43 of 50 posts were the same. The searches at 00:24 and 00:29 were about 6 minutes apart, and 28 posts were the same. The searches at 00:24 and 00:31 were about 7 minutes apart, and 21 posts were the same. On November 13, the searches at 23:00 and 23:05 were 5 minutes apart, and 11 posts were the same. Any two searches more than one hour apart had 0 posts in common.

Two searches (SGT)	Time between them	Posts in common
00:29:59 and 00:31:25 on Nov 14	1.5 minutes	43
22:31:06 and 22:31:40 on Nov 13	34 seconds	47
00:24:07 and 00:29:59 on Nov 14	about 6 minutes	28
00:24:07 and 00:31:25 on Nov 14	about 7 minutes	21
23:00:13 and 23:05:32 on Nov 13	about 5 minutes	11
Any two searches more than one hour apart	more than 1 hour	0

Searches a few minutes apart return mostly the same posts. To get more posts, search again after some time (about one hour in our data), and then merge the results by id. Our 8 searches (one of them with quotes) gave 224 different posts. Search cost $0.006224 in total, which is about $0.0278 per 1,000 different posts ($0.006224 ÷ 224 × 1,000).

Search matches words, not phrases

The keyword matches single words, not the phrase. The chart shows our manual check of the 50 results from 22:31. 14 posts were about software or APIs. 9 had api or threads only in a link in the text, such as api.whatsapp.com or ?api=1.

In 12 posts, api was a word in another language (in Malay and Indonesian, api means "fire", and kereta api is a train). 15 posts did not contain either word. None of the 50 posts was about the Threads API. The post with the most replies (1,696) did not contain either word.

At 23:07, we searched again with English quotes, "threads api". It returned 39 posts, and none of them contained the phrase. We checked only these 50 posts by hand. We filtered the other results only with the text rule below.

Thus, filter the results again on your side. The code below merges the CSV files of several runs, removes duplicates and keeps a post only if its text matches both rules. We ran it on six runs: 22:31, 23:00 and 23:05 on November 13, and 00:24, 00:29 and 00:31 on November 14. The 6 files had 210 different posts, and 0 of them contained both threads and API in capitals.

"""Merge the posts.csv files of several runs, remove duplicates, then filter on the text. Usage: python3 merge_filter.py runs/posts_*.csv"""
import csv, re, sys

MUST = [re.compile(r"\bthreads?\b", re.I), re.compile(r"\bAPI\b")]   # both must match; change them for your topic

seen, kept = {}, []
for path in sys.argv[1:]:
    with open(path, encoding="utf-8") as f:
        for row in csv.DictReader(f):
            seen.setdefault(row["id"], row)          # keep the first row for each post
for row in seen.values():
    if all(rx.search(row["text"] or "") for rx in MUST):
        kept.append(row)
print(f"{len(sys.argv) - 1} files, {len(seen)} unique posts, {len(kept)} with both threads and API in the text")

To get less noise, use a more specific term (a product name, an event name or a hashtag). You can also start from accounts and use threads/user_posts to read the accounts that you follow.

Cost per 1,000 rows and time per call

The cost table includes all 60 successful calls from 22:31 on November 13 to 00:31 on November 14. Their total charge was $0.032356. The cost per 1,000 rows is "total charge ÷ rows returned × 1,000". We count the rows that the API returned, and each call to a single-row capability (details, profile) counts as 1 row.

Capability	Successful calls	Rows returned	Total charge	Per 1,000 rows
threads/search (up to 50 per call)	8	383	$0.006224	$0.0163
threads/user_posts (up to 50 per call)	12	230	$0.003892	$0.0169
threads/comments (one call per post)	17	329	$0.009452	$0.0287
threads/post_detail (1 row per URL)	17	17	$0.009452	$0.5560
threads/profile (1 row per account)	6	6	$0.003336	$0.5560
Full script: search + detail + replies + profile	3 × 4	228	$0.007338	$0.0322

threads/search and threads/user_posts return up to 50 rows per call, so 1,000 rows cost less than 2 cents. threads/comments returned 329 rows in 17 calls, which is about 3 cents per 1,000 rows. post_detail and profile return 1 row per call, which is $0.556 per 1,000 rows. Thus, if a list call already gives a field (likes, replies, time), do not call the details for each post. The three full script runs returned 228 rows and cost $0.007338, which is $0.0322 per 1,000 rows.

Here is an example with our own assumptions. If you run this script once each hour for one keyword, a day is 24 × $0.002446 = $0.0587, and 30 days are about $1.76. To also read the post list of one account in each run, add $0.000556 per run. That is $0.40 more in 30 days. The real cost is the charged_usd value in each response. To use your own volume, multiply the last column of the table by your monthly rows and divide by 1,000.

The time data includes only the 48 successful calls that had a recorded time for each call. The three full script runs recorded only their start and end.

search took 17.9 to 26.6 seconds, median 20.1 seconds. post_detail took 6.4 to 27.4 seconds, median 9.0 seconds. comments took 6.4 to 88.0 seconds, median 13.7 seconds. profile took 19.2 to 57.7 seconds, median 21.9 seconds. user_posts took 27.2 to 78.2 seconds, median 38.1 seconds.

All of these are sync calls, so a timeout of 180 seconds in the script is sufficient. To look up many accounts at once, add "mode": "async" to the request body. Then poll the task ID that you get. The API hint describes this.

The call() function in the script handles two errors. A 429 means that your own key went over its rate limit, so wait 60 seconds and try again. When the API returns 503, charged_usd in the response is 0, retryable is true, and retry_after gives a suggested wait in seconds. Wait for that time and try again, and the retry gives a result. Do not record a 503 as "no data". The function tries three times and raises an error only if all three fail. For a scheduled job, you can record the failed keywords and run them again in the next round.

Replies form a tree: the official replies and conversation endpoints

Threads replies can nest many levels deep. The official API has two endpoints for this tree. GET /{media-id}/replies returns only the first level of replies. Each reply has a has_replies field that tells you if there are deeper replies, and you call the endpoint again to go one level down. GET /{media-id}/conversation returns all levels as one flat list, sorted by time (the reverse parameter sets the order, and the default is newest first). The docs add that conversation is only for top-level posts that have replies (Retrieve media replies and conversations).

Replies form a tree. The replies endpoint reads one level at a time, and the conversation endpoint returns the full tree as a flat list

The official docs give three more limits for these two endpoints. username and permalink come back only for public users and for your own user. is_verified and profile_picture_url are on direct replies only (Meta added these fields on December 16, 2025).

hide_status has six values: NOT_HUSHED, UNHUSHED, HIDDEN, COVERED, BLOCKED and RESTRICTED, so filter on this field before you count anything. To read replies, you need threads_read_replies, and that permission is on the Tech Provider list too (Retrieve and manage replies). The EveryInfra threads/comments capability does not need these permissions. It costs $0.000556 per call and returns public replies with reply_to. The catalog does not state the order of the replies.

Since February 13, 2026, an author can also turn on reply approvals. New replies stay hidden until the author approves them. The author reads them with GET /{media-id}/pending_replies, where the status is pending or ignored (Reply management). This matters for outside analysis. On a post with approvals turned on, the public can see only the approved replies. Thus, the reply count and the number of replies that you can read can be different.

Meta's terms, robots.txt and the limits of public data

Before you read public Threads data with code, read three Meta documents. We read them on November 13 and 14, 2026. They apply in the same way to your own scraper and to a third-party data API (EveryInfra included). This article is not legal advice. Before you start, check the Meta terms and the laws where you are.

The first document is the Threads Terms of Use. Section 3(a) lists what users must not do. Item (iv) says that users must not use "any robot, spider, crawlers, scraper or other automatic device, process, software or queries" to access the Threads Service "to monitor, extract, copy or collect information or data". It also prohibits "any manual process to do the same". The start of the same section also prohibits causing or permitting a third party to do these things.

The second document is the Threads robots.txt. The copy that we saved at 21:37 SGT on November 13, 2026, has 389 lines. The first four comment lines prohibit automated data collection on Threads without written permission from Threads. They also say that the listed crawlers must obey the Meta Automated Data Collection Terms. At the end, the file gives User-agent: * and Disallow: / for all crawlers that it does not name.

The third document is the Meta Terms of Service. Section 3.2, item 3, says that you may not access or collect data from Meta products with automated means without prior permission from Meta. It also says that this applies "regardless of whether such automated access or collection is undertaken while logged-in to a Facebook account". The top of the page also says that new terms start on January 20, 2027.

Only the public side is in scope: public posts, public replies and public profiles

The EveryInfra Threads capabilities return only content that the public can see. They do not sign in to any account, and they do not read private messages, private accounts or friends-only posts. The is_private field from threads/profile tells you if an account is private. On October 29, 2026, Threads began to test "Threads Friends" in Ireland, Italy and Japan. With it, a user can share a post with up to 50 friends only (Social Media Today, October 29, 2026; Engadget). These posts are also not public data.

Content	Official API with Advanced Access	EveryInfra Threads capabilities
Posts and replies from public accounts	Yes, after App Review; profile lookup needs 100 or more followers	Yes
Posts from private accounts	Your own account only	No
Friends-only posts ("Threads Friends" test)	Not in the docs that we read	No
Private messages	No read endpoint in the docs that we read	No
Replies that wait for approval	The post author only (pending_replies)	No
Insights: views, follower demographics	Your own posts and accounts that gave access	No; user_posts returns view_count for public posts

Newsrooms and public agencies often use four rules for this type of data. Keep only the fields that the analysis needs (post ID, time, text, counts), and do not keep profile pictures or profile links. Hash or remove the usernames of private individuals; you can keep the names of organization accounts. Set a retention period and delete the data when it ends. Publish only aggregate results, and do not post screenshots of replies from private individuals. Does your analysis include people in the EU or the UK? Then first read the guidance of the local data protection authority.

When the official Threads API or Meta's research tools are the better choice

In three cases, the official route is a better fit than a third-party data API.

The first case is when you manage your own account, or an account that a client authorized. Only the official API can publish posts, reply, hide replies, approve replies and read insights (views, likes, replies, reposts, quotes, follower count and follower demographics). A third-party data API reads public data only. It cannot post, and it cannot see views or follower demographics from insights. The official API does not charge per call. The budget is 4,800 × impressions calls per day, so an account with 10,000 impressions gets 48 million calls per day.

The second case is when you are a researcher at a university or a nonprofit. The web tool of Meta Content Library includes posts from public Threads profiles with 100 or more followers. It has keyword trend charts and producer lists. The Secure Data Access Center (CASD) in France reviews each application, and use inside the Meta Secure Research Environment is free. There are three limits.

Only academic or nonprofit researchers can apply. You analyze data inside a controlled environment. The Content Library API endpoints on that page do not include Threads (the web tool does). This route has a documented data source, and CASD reviews each application. It suits research that needs a source that others can trace and reproduce, with an ethics review.

The third case is when you only need trending topics in the USA or Japan. /trending_topics lists topic titles with an app access token and basic access, and topics change at most once per hour. To read the posts under a topic, you need Advanced Access. The docs also say that you may not transfer or modify the trending data.

Other cases need Advanced Access on the official route. Examples are posts from any public account without the owner's token, keyword search on other people's posts, and replies under other people's posts. The table shows the best route for each case.

What you need	Better route	Main reason
Publish, reply, hide or approve replies on your own account	Official API	Only the official API can write
Views and follower demographics of your own account	Official API insights	Insights read only accounts that gave access
An academic study with an ethics review	Meta Content Library	A documented source in a controlled environment
Trending topic titles in the USA or Japan	Official /trending_topics	Basic access is enough for the titles
Public posts and replies of other accounts	Third-party data API	No Meta developer app; the three documents above also apply

Use in other fields: sentiment of replies to public agencies and newsrooms

To score the public replies under a notice or a story, use four steps. Each step uses a capability from the sections above.

Step 1: select the posts. Use threads/user_posts to get the recent posts of the agency account (up to 50 per call). Sort them by comment_count and select the posts that have enough replies. On a post with few replies, the sentiment score changes a lot from one reply to the next. Step 2: get the replies.

Call threads/comments for each post. You get the reply text, the time, the like count and reply_to. Step 3: clean the data. Remove the replies from the agency account itself (filter on author_username). Remove replies that contain only emoji or links. Group the replies by language.

Step 4: score the replies. For English replies, you can start with VADER, a sentiment model that uses a dictionary and rules (Hutto and Gilbert, ICWSM 2014). It gives a score from -1 to 1. VADER needs no training data, and its authors tuned it for short social media text. For other languages, use a model for that language. Or use a large language model with a fixed prompt that sorts each reply into positive, negative or neutral.

We tried step 1 on three news accounts. From 23:03 to 23:05 SGT on November 13, 2026, we used threads/user_posts to get the latest 50 posts of each account. Then we grouped the posts by reply count. The New York Times had 9 posts with 20 or more replies, a median of 5 and a maximum of 68. BBC Chinese had 5 posts with 20 or more, a median of 1 and a maximum of 186.

CNN en Español had 46 posts with no replies, and its top post had 10. Thus, news accounts are very different in how many posts you can score, and the Spanish-language account gave almost no usable sample. The three calls cost $0.001668 in total.

Account (SGT)	Posts	0 replies	1 to 4	5 to 19	20 or more	Median	Max	Sum of replies
The New York Times (23:03)	50	5	20	16	9	5	68	561
BBC Chinese (23:03)	50	16	19	10	5	1	186	529
CNN en Español (23:04)	50	46	3	1	0	0	10	14

We then tried steps 2 to 4 on two New York Times posts. At 00:24 and 00:28 SGT on November 14, 2026, we used threads/comments with the recommended method above. The post of November 11 returned 30 replies, and the post of November 12 returned 17. We removed empty texts and replies from @nytimes, which left 28 and 15 replies. Then we scored them with vaderSentiment 3.3.2 and its default dictionary, with no changed settings. A compound score of 0.05 or more is positive, -0.05 or less is negative, and the rest is neutral.

Of the 28 replies, 14 were positive, 7 neutral and 7 negative, with a mean of 0.131. Of the 15 replies, 7 were positive, 5 neutral and 3 negative, with a mean of 0.149. Each sample has only 15 to 28 replies, and we did not check the scores by hand.

Thus, use this result only as a demo of the method. It does not show what readers think of these two stories. The two means differ by only 0.018. In samples this small, one or two more negative replies can remove that difference. Before you compare two posts, get reply samples of the same size, and then check if the difference stays.

Likes are not spread evenly across replies, and this affects how you weight the scores. On November 11, 2026, the 30 replies returned for the NYT post had 1,053 likes in total. The top reply had 901 of them, and the median of the other 29 was 1 like. On November 12, 2026, the 30 replies returned for a BBC Chinese post had 4,424 likes in total. The top reply had 1,896, and the median was 2.5.

If you weight scores by likes, the top one or two replies decide the result. If you do not weight them, a reply with 0 likes counts the same as a reply with hundreds. Calculate both, and give both in the report.

Replies in Chinese need a different model. On the BBC Chinese post at 00:25, 25 of the 30 replies contained Chinese characters, and 14 of them contained common traditional characters. One reply had no text, and the mean length was 17 characters.

At 00:29, a different BBC Chinese post returned 28 replies: 22 contained Chinese characters and 5 had no text. The replies are short, they mix simplified and traditional characters, and many are empty.

Thus, an English dictionary model does not work here. Use a model that supports Chinese, or a large language model with a fixed prompt for three classes. Then check a sample by hand. The 9 replies returned for the CNN en Español post were all in Spanish, with a mean length of 27 characters. They also need a Spanish model. Group the replies by language before you score them, report each group separately, and do not average scores across languages.

This method has five data limits. Your report must state each one.

The five limits are coverage, order bias, reply approval and hidden replies, who replies, and model error. For "who replies", one outside number helps. The Reuters Institute Digital News Report 2026 gives the average for 48 markets. For the first time, social media and video platforms passed news sites and apps as the most common online news source, at 54% against 51%. The source is the Reuters Institute Digital News Report 2026, June 16, 2026.

But the people who comment under a post are only a part of the people who read news there. Sarcasm, rhetorical questions and technical words cause the most model errors, so check a sample by hand before you publish.

The five limits and what to write in the report:

Limit	How it changes the result	What to write in the report
Coverage	One replies call does not always return all replies	"M of N replies"
Order bias	You get only one part of the replies, so early or top replies can be missing	Which part you got, and when
Reply approval and hidden replies	Public results show only approved replies that are not hidden, so scores lean positive	Whether approval was on; hidden replies are not in the sample
Who replies	People who reply do not represent the public or people who do not use Threads	Limit the result to "people who reply on Threads"
Model error	Sarcasm, rhetorical questions and technical words cause the most errors	How many replies you checked by hand, and the agreement rate

For more on these sampling problems, see Social Media Research Data: Test Sample Stability First and Health Misinformation Monitoring: Tylenol, One Year On. When you state these five limits, this type of analysis can answer relative questions, such as "on the same account, which topics get more negative replies". It cannot answer absolute questions, such as "is the public satisfied with this agency".

Get started: from one call to a daily run

To start from an account and read Instagram posts and comments, see Instagram Scraper Python: Scrape Instagram Posts and Comments Three Ways.

Step 1: sign up and create an API key. Find the Threads capabilities and their prices in the API market. Then follow the quickstart in the docs and call threads/search once with curl to test the key. Step 2: save the Python script from this article, put your key in the EVERYINFRA_API_KEY environment variable, and run it once. Check the fields in posts.csv and replies.csv.

Step 3: for a daily run, use cron or your own scheduler. Write each day to a different file, then remove duplicates and merge later. Each Threads capability has a page with its parameters, examples and response fields. The pages are search, profile, user posts, post detail, replies and discover profiles. The overview is on the Threads Scraper API page.

If you use an AI tool that supports MCP, such as Claude or Cursor, you do not need to write code. Add https://api.everyinfra.com/mcp as a remote MCP server with the same key. The tool list then shows everyinfra_call_api, and you can ask the AI in plain language to search Threads posts and read replies. The setup steps are on the MCP page. The same API also reads public data from Instagram, Reddit and other platforms, and all prices are on the pricing page.

Recent changes: four Threads events from the last 30 days

November 10, 2026: Threads adds advanced search filters. The @threads account posted that the search bar now has a filters menu. You can filter by date range, community and post type, and you can ask for exact matches. The sources are the @threads post and Social Media Today on the same day. What this means for you: manual search in the app can now narrow by date. The developer endpoint /keyword_search has had since and until since July 14, 2025, but the two sets of filters are not the same. The "community" filter in the app has no parameter in the API docs.

October 30, 2026: Meta's new commercial terms take effect. With the new terms, Meta can use automated software to crawl websites of business accounts, for advertising and business products. Most newsrooms use a Meta business account to manage Facebook Pages, Threads accounts and Instagram profiles. Groups such as the UK News Media Association objected in public (Nieman Lab, October 2026; terms preview). What this means for you: on Threads, a newsroom is both a subject of analysis and a party to Meta's data terms. Before you analyze your own account data, check which version of the commercial terms your organization signed.

October 29, 2026: Threads tests "Threads Friends". People can share a post with up to 50 friends. The test runs in Ireland, Italy and Japan (Social Media Today). What this means for you: Threads now has one more type of content that is not public. If you measure opinion on Threads, friends-only posts are outside your sample, the same as posts from private accounts. Say this in your report.

October 21, 2026: Meta reports third-quarter results. Family daily active people averaged 3.64 billion in September 2026, up 3% year over year (Meta Reports Third Quarter 2026 Results). On the earnings call that day, Mark Zuckerberg said that Threads had passed X in monthly actives, but he gave no number. The transcript says that Threads "has now overtaken X in monthly actives" (Q3 2026 earnings call transcript). Music Ally reported the quote on October 22, 2026 (Music Ally).

The last Threads number that Meta published was 500 million monthly users on June 16, 2026 (per 24/7 Wall St. on Yahoo Finance). What this means for you: public discussion on Threads keeps growing, but there is no official user count to check against. Threads has no public user count, so you cannot weight a sample to all internet users.

FAQ

Is the Threads API free? What is the Threads API pricing?

This question comes from the Google suggestions "threads api free" and "threads api pricing" (read November 13, 2026). Meta does not charge per call for the Threads API, and the docs have no price list. The limits are the call budget (4,800 × impressions per 24 hours) and the permissions. To read public data from other people, your app must pass App Review and, for a business app, become a Tech Provider.

That costs no money, but it costs time, and approval is not certain. A pay-per-call API works the other way: no review, and you pay per call. In the EveryInfra public catalog on November 13, 2026, threads/search costs $0.000778 per call and the other six Threads capabilities cost $0.000556 per call. Failed calls and empty results are free.

How do I get a Threads API key or token?

This question comes from the suggestions "threads api key" and "threads api token". The official API has no single key. It uses OAuth user access tokens. You create an app with the Threads use case in the Meta developer dashboard. A user approves the permissions in the authorization window, and you get an authorization code.

You exchange the code for a short-lived token (valid for 1 hour), and then for a long-lived token (valid for 60 days). You can refresh it before it expires (Get started). A permission grant from a public profile is valid for 90 days and extends when you refresh the long-lived token. A grant from a private profile cannot be extended. Trending topics use a different token, the app access token.

Why does Threads API keyword search return only my own posts?

This question comes from posts on the Meta developer forum (3633404910150925, 1476322604349910). Your app is not approved for threads_keyword_search. The docs say that, without approval, "the search is performed only on posts owned by the authenticated user". "Ready for testing" in the dashboard does not mean approved. Approval goes through App Review, and a business app must first become a Tech Provider.

Can the Threads API read replies under other people's posts?

This question comes from the Stack Overflow post "Does Meta Threads API Allow Reading Timeline Posts and Liking Others' Posts?", which had 0 answers on November 13, 2026. The docs say that the reply management API is for replies "to users' own Threads posts". Without Advanced Access for threads_basic, a single-post lookup returns only posts from testers. To read public replies under other people's posts, the official route needs Advanced Access for these permissions. A pay-per-call API reads them from the post URL, for example with threads/comments.

Is there a free Threads scraper? Can I use one from GitHub?

This question comes from the suggestions "threads scraper free" and "threads scraper github". junhoyeo/threads-api is an early unofficial Threads client on GitHub. Its README says that development stopped on September 8, 2023, after a communication from Meta. The repository is archived.

The author writes that using or sharing the code might violate Meta's terms of service. The three Meta documents from the section above apply to your own scraper and to a third-party data API. With your own scraper, you must also update the parser after each layout change.

Is there an official Threads API Python SDK?

This question comes from the suggestions "threads api python" and "threads api example". Meta provides an open-source sample app in Node.js, fbsamples/threads_api, and a Postman collection. The docs show no official Python SDK. The sample app README also says that Threads apps do not accept localhost redirect URLs. To test on your machine, map a domain in your hosts file.

The top YouTube result for "threads api python" (published January 28, 2025, about 19 minutes) also covers app setup and tokens for the official API. To call the official API from Python, you send HTTP GET requests with requests. To call a pay-per-call API, you send one POST. The script in this article uses only requests.

References

1. Threads API overview, Meta for Developers, December 22, 2025, https://developers.facebook.com/documentation/threads/overview
2. Get started (Threads API), Meta for Developers, https://developers.facebook.com/documentation/threads/get-started
3. Retrieve user posts, Meta for Developers, April 14, 2026, https://developers.facebook.com/documentation/threads/retrieve-and-discover-posts/retrieve-posts
4. Threads profiles, Meta for Developers, https://developers.facebook.com/documentation/threads/threads-profiles
5. Keyword and topic tag search, Meta for Developers, January 21, 2026, https://developers.facebook.com/documentation/threads/keyword-search
6. Retrieve media replies and conversations, Meta for Developers, https://developers.facebook.com/documentation/threads/retrieve-and-manage-replies/replies-and-conversations
7. Retrieve and manage replies, Meta for Developers, https://developers.facebook.com/documentation/threads/retrieve-and-manage-replies
8. Reply management, Meta for Developers, https://developers.facebook.com/documentation/threads/reply-management
9. Mentions, Meta for Developers, https://developers.facebook.com/documentation/threads/threads-mentions
10. Trending topics, Meta for Developers, https://developers.facebook.com/documentation/threads/trending-topics
11. Threads Insights API, Meta for Developers, https://developers.facebook.com/documentation/threads/insights
12. Embed a Threads post (oEmbed), Meta for Developers, https://developers.facebook.com/documentation/threads/tools-and-resources/embed-a-threads-post
13. Threads Changelog, Meta for Developers, August 18, 2026, https://developers.facebook.com/documentation/threads/changelog
14. Access Levels, Meta for Developers, June 30, 2026, https://developers.facebook.com/documentation/development/graph-api/overview/access-levels
15. Tech Providers, Meta for Developers, https://developers.facebook.com/docs/development/release/tech-providers/
16. The Threads API is finally here, Meta for Developers blog, June 18, 2024, https://developers.facebook.com/blog/post/2024/06/18/the-threads-api-is-finally-here/
17. Threads keyword_search returns only my own posts, Meta Developer Community, https://developers.facebook.com/community/threads/3633404910150925/
18. How can a self-use Threads app get public keyword search approval, Meta Developer Community, October 21, 2026, https://developers.facebook.com/community/threads/2883329558707631/
19. keyword_search returns the same post and repeats the same pagination cursor, Meta Developer Community, https://developers.facebook.com/community/threads/1476322604349910/
20. Threads App Review for a first-party brand app, Meta Developer Community, https://developers.facebook.com/community/threads/1094128013493014/
21. Threads App Review for an internal business app, Meta Developer Community, https://developers.facebook.com/community/threads/2580213639125398/
22. Does Meta Threads API Allow Reading Timeline Posts and Liking Others' Posts?, Stack Overflow, https://stackoverflow.com/questions/79455370/does-meta-threads-api-allow-reading-timeline-posts-and-liking-others-posts
23. fbsamples/threads_api (sample app), GitHub, https://github.com/fbsamples/threads_api
24. Threads API Postman collection, Meta on Postman, https://www.postman.com/meta/threads/overview
25. junhoyeo/threads-api (archived), GitHub, September 8, 2023, https://github.com/junhoyeo/threads-api
26. Threads Terms of Use, Instagram Help Center, https://help.instagram.com/769983657850450
27. threads.com robots.txt, Threads, November 13, 2026, https://www.threads.com/robots.txt
28. Automated Data Collection Terms, Meta, https://www.facebook.com/legal/automated_data_collection_terms
29. Meta Terms of Service, Meta, https://www.facebook.com/terms/
30. Commercial Terms (preview), Meta, https://www.facebook.com/legal/commercial_terms_preview
31. Meta Content Library, Meta Transparency Center, https://transparency.meta.com/researchtools/meta-content-library/
32. Meta Content Library and API documentation, Meta for Developers, https://developers.facebook.com/docs/content-library-and-api/
33. Centre d'accès sécurisé aux données (CASD), CASD, https://www.casd.eu/en/
34. Meta Reports Third Quarter 2026 Results, Meta Investor Relations, October 21, 2026, https://investor.atmeta.com/investor-news/press-release-details/2026/Meta-Reports-Third-Quarter-2026-Results/default.aspx
35. Meta's Threads Now Has More Monthly Users Than X, 24/7 Wall St. on Yahoo Finance, June 16, 2026, https://finance.yahoo.com/media-advertising/articles/meta-threads-now-more-monthly-161328077.html
36. @threads post on advanced search filters, Threads, November 10, 2026, https://www.threads.com/@threads/post/DfkgGO8Jedq
37. Threads adds advanced search filters, Social Media Today, November 10, 2026, https://www.socialmediatoday.com/news/threads-adds-advanced-search-filters/874339/
38. Threads tests smaller group sharing option, Social Media Today, October 29, 2026, https://www.socialmediatoday.com/news/threads-tests-smaller-group-sharing-option/873271/
39. Meta Is Testing 'Threads Friends' For Sharing Posts With Smaller Groups, Engadget, October 29, 2026, https://www.engadget.com/2301804/meta-is-testing-threads-friends-for-sharing-posts-with-smaller-groups/
40. Third Quarter 2026 Results Conference Call (transcript), Meta Investor Relations, October 21, 2026, https://s21.q4cdn.com/399680738/files/content_files/META-Q3-2026-Earnings-Call-Transcript.pdf
41. Meta says Threads now has more monthly active users than X, Music Ally, October 22, 2026, https://musically.com/2026/10/22/meta-says-threads-now-has-more-monthly-active-users-than-x/
42. Legal experts warn Meta's new terms still grant broad scraping permissions, Nieman Lab, October 2026, https://www.niemanlab.org/2026/10/legal-experts-warn-metas-new-terms-still-grant-broad-scraping-permissions-despite-language-changes/
43. Digital News Report 2026: executive summary, Reuters Institute, June 16, 2026, https://reutersinstitute.politics.ox.ac.uk/digital-news-report/2026/dnr-executive-summary
44. VADER: A Parsimonious Rule-based Model for Sentiment Analysis of Social Media Text (Hutto & Gilbert, ICWSM 2014), AAAI / ICWSM, 2014, https://doi.org/10.1609/icwsm.v8i1.14550
45. cjhutto/vaderSentiment, GitHub, https://github.com/cjhutto/vaderSentiment
46. Requests: HTTP for Humans, Python Software Foundation / Requests docs, https://requests.readthedocs.io/en/latest/
47. EveryInfra public catalog (Threads capabilities), EveryInfra, November 13, 2026, https://api.everyinfra.com/api/v1/social/catalog

We opened and checked all links on November 13, 2026 (SGT). Dates are the update or publish dates that the pages show.

---

Originally published on the EveryInfra blog: Threads API in Python: What the Official API Reads, and How to Get Public Posts and Replies. This article was written with AI assistance; the numbers come from the API calls and sources linked above, and were checked before publishing.

EveryInfra is a pay-per-call data API for AI agents and developers: everyinfra.com.