# How to Get All Replies to a Tweet with an API
Canonical: https://www.twitterapis.com/answers/how-to-get-all-replies-to-a-tweet-api
Description: Call tweet/replies with the parent post id, loop the cursor, and walk nested branches by reply id. Each page is one read at $0.0008 on TwitterAPIs.
Generated: 2026-08-26T06:52:18.722Z
---[Pricing](/pricing)[Docs](https://docs.twitterapis.com)[Blog](/blogs)

Compare and Tools

[MCP Server](/mcp)[Integrations](/integrations)[Language Clients](/sdk)[Free Tools](/tools)[Twitter ID Finder](/tools/twitter-id-finder)[Twitter API Cost Calculator](/twitter-api-cost-calculator)[Twitter Search API](/twitter-search-api)[Twitter Followers API](/twitter-followers-api)[Twitter Scraper](/twitter-scraper)[Twitter API Use Cases](/twitter-api-usecases)[Twitter API Rate Limits](/twitter-api-rate-limits)[Twitter Unofficial API](/twitter-unofficial-api)[Twitter Free API](/twitter-free-api)[Twitter API Alternatives](/twitter-api-alternatives)[TwitterAPIs vs Tweepy](/twitterapis-vs-tweepy)[TwitterAPIs vs RapidAPI](/twitterapis-vs-rapidapi)[TwitterAPIs vs GetXAPI](/twitterapis-vs-getxapi)

Company

[About](/about)[Status](/status)[Affiliates](/affiliates)[Trust](/privacy-and-data-handling)[Changelog](/changelog)[Contact](/contact)

[Start Free](/signup)

1.  [Home](/)
2.  /[Answers](/answers)
3.  /How do you get all the replies to a tweet?

# How do you get all the replies to a tweet?

Last updated August 24, 2026

GET tweet/replies takes the parent post id and returns its direct replies one cursor page at a time. Deeper branches are their own fetches: hand a reply id back as the id and the tree widens a level. Each page meters at a flat $0.0008, and reply\_count from tweet/detail tells you how many branches you are chasing before the walk starts.

Every rate here is the pricing TwitterAPIs publishes. The billed rate is $0.0008 per call; $0.04 per 1,000 tweets is derived from it at a full 20-tweet page, which is the default page size rather than a guaranteed yield (source: [twitterapis.com/pricing](/pricing)).

## The request shape, and the two query keys

GET https://api.twitterapis.com/twitter/tweet/replies takes id, the numeric identifier of the parent post, and that is the only required parameter. The one optional parameter is cursor, which you omit on the opening request and fill from the previous response on every request after it. Authorisation rides on an Authorization Bearer header carrying your key, and the same value in an x-api-key header is accepted if that suits your stack better. No page-size knob, no ordering knob and no depth knob exist on this route, so the entire request surface is two query keys. There is no session field in that parameter list either, so your key is the only credential in play and nothing has to be registered before the first call. The response envelope is just as small: a tweets array, a count describing that page, and next\_cursor.

## Every field a reply row carries

Each element of tweets is a full post object rather than a trimmed summary. id arrives as a string rather than a number, deliberately, because a 19 digit identifier loses its trailing digits to JavaScript number precision. text holds the complete body with URLs already expanded, which means link extraction from a reply needs no second resolution step. created\_at uses X's own date format. author nests the numeric user id, the handle, the display name and the verification flags, so labelling a response costs nothing extra. After those sit favorite\_count, retweet\_count, reply\_count and, where the upstream source exposes it, view\_count. Every one of those counters is a reading taken at fetch time rather than a running total, so two pulls a day apart will disagree and neither of them is wrong. Store your own fetch timestamp beside each row or later comparisons mean nothing.

## One level down, never the whole tree

The route is documented as returning the direct replies to a given post, so a single call covers exactly one level of the conversation. A reply written underneath another reply belongs to that child, and you reach it by calling the same route again with the child's id sitting in the id slot. Nothing else about the request changes, because any post can act as a parent here. That is the mental model to hold: this is not a tree endpoint that happens to paginate, it is a one-level endpoint you call repeatedly. Since each returned row carries its own reply\_count, you can look at a branch and know whether it has children before spending anything, which means a leaf never costs a call to prove it is a leaf. On a wide thread that pruning removes most of the calls you would otherwise make.

## The termination condition that actually holds

Send the first request with no cursor, copy next\_cursor out of the response into the next request, and repeat. The cursor contract in the reference is worth reading closely before you write the loop, because it is not uniform across the API. List and affiliate routes hand back null on the final page, while the follower graph routes keep returning a non-null cursor even when they are finished. The only stop test that holds everywhere is therefore an empty collection array, and a loop written against that rule survives being pointed at a different endpoint later. Apply it here and your walk cannot run past the end or spin on a cursor that never nulls. Key your store on the reply id string as well, so re-running a page overwrites rows rather than duplicating them into your dataset.

## Walking a wide argument without recursion

A busy post is wide before it is deep, so a queue beats recursion every time. Push the parent id, pop an id, page that id to exhaustion, then push any returned reply whose reply\_count is above zero back onto the queue. That turns an unpredictable tree into a flat loop you can pause, resume, checkpoint and budget, which recursion makes awkward. Give the queue a hard call cap and a maximum depth, because a thread that keeps growing while you crawl has no natural end and will happily consume whatever allowance you give it. Recording which ids you have already expanded stops a second pass re-walking branches the first pass finished. It also makes the job restartable: a crashed run resumes from the queue rather than from the top of the conversation.

## Sizing the crawl before you spend on it

Read the parent through tweet/detail first. That call returns the tweet object with reply\_count on it, which is the figure X reports for the post itself, and it converts a guess into an estimate of how many pages you are about to pull. The same object hands you favorite\_count, retweet\_count and view\_count, so one standard read tells you both how large the conversation is and how much attention the post drew. On a post reporting 88 replies you plan a short walk and stop thinking about it. On one reporting 40,000 you decide up front how many levels are worth paying for, and whether the top level alone answers your question. Doing that ordering, detail first and replies second, is the difference between a bounded job and an open-ended one.

## Throughput on a key doing nothing else

One key is allowed 600 requests a minute with 20 in flight at once, and both ceilings apply to this route exactly as they do to every other read. A reply crawl is inherently serial down any single branch, since you cannot request the second page before the first one names its cursor, so concurrency only buys you anything across branches. Run twenty workers against the shared pending-id queue and wall clock stops being about the request allowance and starts being about upstream latency. A thousand page fetches fit inside two minutes of that allowance, which is why throughput is rarely the binding constraint on this particular job. The constraint is usually your own call budget, so cap the queue rather than tuning the worker count.

## The arithmetic on a real discussion

Every page of replies is one standard read at $0.0008, and the tweet/detail lookup you run first is another. Forty pages therefore costs $0.032 plus that one lookup, so even a heated thread lands well under a nickel. Nothing here is metered per record, so a page holding two replies bills exactly what a page holding twenty bills, which is why pruning empty branches matters more than trimming rows. The $0.50 credited to a new account, with no card asked for, buys 625 reads, more page fetches than most conversations on the platform contain. Idle weeks bill nothing at all, because there is no subscription floor sitting underneath the per-call price. That makes an occasional deep crawl cheap in a way a seat-based plan never is.

## What this route will not do for you

tweet/replies returns what other people wrote back, and nothing else. It does not return the author's own connected chain, which is tweet/thread at $0.004 a call and arrives already ordered so you skip the walk entirely. It does not return the posts that quoted the parent, which is tweet/quotes. It does not hand you the parent itself, which is tweet/detail. And it exposes no filter of any kind, so anything you want stripped out, whether that is low-engagement noise or one specific account, gets stripped in your own code after the page has already landed and been billed. If pre-filtering matters more than completeness, a search query scoped with conversation\_id does the narrowing upstream instead, at the same price per page. We bill $0.0008 a call, per our public pricing.

## Which endpoint answers which part of a discussion

What you want

Endpoint

What comes back

The parent post and its totals

tweet/detail

One tweet object carrying reply\_count and view\_count

One level of direct replies

tweet/replies

A tweets array plus count and next\_cursor

A branch under a single reply

tweet/replies with that reply's id

That child's own replies, same envelope

The author's connected chain

tweet/thread

An ordered thread array, billed at $0.004

The commentary people attached

tweet/quotes

Quote posts with the original nested inside

Who reposted without adding words

tweet/retweeters

A users array carrying followers\_count

> When an API response contains more results than can be returned at once, use pagination to retrieve all pages of data.

X Developer Platform, pagination documentation. [Source](https://docs.x.com/x-api/fundamentals/pagination)

## Questions and answers

Does one call return every reply to a post?

No. A single request returns one page of direct replies plus a next\_cursor token. You loop on that token until the tweets array comes back empty, and nested replies sit behind separate calls made with the child reply's id. A post carrying a thousand responses is a loop with a budget attached, never a single fetch. There is no parameter anywhere on the route that would turn it into one, so plan the walk rather than looking for a shortcut.

How do I read the replies to a reply?

Take the id of the reply you care about and pass it as the id parameter on a fresh tweet/replies request. The route treats any post as a parent, so the same call shape walks down as many levels as the conversation has, and nothing in the request tells it which level you are on. Check that reply's reply\_count first, because a zero there means the branch has no children and the call would return an empty page you still paid for.

What identifies who wrote each reply?

Every reply object embeds an author block holding the numeric user id, the handle, the display name and the verification flags, so you never need a second lookup just to label a response. Add favorite\_count and created\_at from the same row and you can rank and order responses without touching another endpoint. Key any account-level aggregation on the user id rather than the handle, since handles change and get recycled while the numeric id stays put.

How do I know how many replies to expect?

Fetch the parent through tweet/detail and read reply\_count off the returned tweet object. That figure is what X reports for the post itself, so it sets the scale of the crawl before you commit any budget to it. Pair it with view\_count from the same response and you can judge whether the conversation is worth walking in full, sampling at the top level, or skipping. One standard read buys you that entire decision.

When does the pagination loop actually stop?

Stop when the tweets array is empty, not when next\_cursor is missing. The documented cursor behaviour differs by endpoint family: list and affiliate routes null the cursor on the last page, while follower graph routes keep returning one indefinitely. Testing the array is the single rule that works everywhere, so a loop written that way survives being pointed at a different route later. Treating a null cursor as the only stop condition is how a crawl silently spins.

Why is the reply id a string rather than a number?

Post ids run to 19 digits, which overflows the precision an ordinary JavaScript number can hold, so the API serialises every id as a string to keep the trailing digits intact. Store and compare them as text, and use that string as your deduplication key throughout. A silently rounded id is the usual reason two crawls of the same thread disagree on row counts, and it is invisible until two rows that should be distinct collide in your database.

Can I filter replies before they are billed?

No. The route exposes only id and cursor, so there is no engagement floor, no language filter and no author exclusion available at request time. Everything you want removed comes out in your own code after the page has arrived and the call has metered. If pre-filtering matters more than completeness, run a search query scoped with conversation\_id instead and let the operators do the narrowing upstream, which costs the same per page but returns fewer rows you do not want.

How fast can I crawl a large thread?

The ceiling is 600 requests a minute per key with 20 concurrent, the same allowance every read gets on this API. Paging down one branch is serial because each page names the next cursor, so the concurrency only helps when you fan out across separate branches. Twenty workers pulling from a shared queue of pending ids is the shape that uses the allowance without hitting it, and at that rate a thousand pages clears in under two minutes.

What does a full reply pull cost?

Each page is one standard read at $0.0008, as is the tweet/detail lookup you run first. Ten pages therefore lands under a cent, and forty pages is $0.032 in total. Because billing attaches to the call rather than to each record, a sparse page costs exactly what a full one does, which is the argument for pruning childless branches rather than trimming rows. A week with no crawls bills nothing, since there is no monthly floor.

Can I use this for sentiment analysis?

Yes, the reference names measuring reply sentiment as a use for it. Each row gives you the reply text with URLs expanded, its author block and its engagement counters, which is the raw material a classifier needs and enough to weight loud responses differently from quiet ones. Page the full set before scoring, because stopping after the opening page biases the sample toward whatever X chose to surface at the top of the conversation rather than toward what people actually said.

## Keep reading

-   [Twitter Engagement API](/twitter-engagement-api?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-all-replies-to-a-tweet-api)
-   [Twitter Analytics API](/twitter-analytics-api?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-all-replies-to-a-tweet-api)
-   [REST API documentation](https://docs.twitterapis.com/docs)
-   [How does Twitter API pagination work?](/answers/how-does-twitter-api-pagination-work?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-all-replies-to-a-tweet-api)
-   [Cost calculator](/twitter-api-cost-calculator?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-all-replies-to-a-tweet-api)
-   [Quote tweets and retweeters](/answers/how-to-get-quote-tweets-and-retweeters-api?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-all-replies-to-a-tweet-api)
-   [Pulling a whole thread in one call](/answers/how-to-get-a-full-twitter-thread-api?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-all-replies-to-a-tweet-api)

### Start with $0.50 in free credits

No credit card. Roughly 12,500 tweets to test every endpoint.

[Get your API key](/signup?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-all-replies-to-a-tweet-api)[See pricing](/twitter-engagement-api?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-all-replies-to-a-tweet-api)

[

TwitterAPIs](/)

The cheapest pay-as-you-go Twitter and X API. $0.0008 per call, which works out to $0.04 per 1,000 tweets on a full 20-tweet page. No subscriptions and no developer account.

## Product / API

-   [Pricing](/pricing)
-   [Pay-Per-Use Pricing](/pay-per-use-pricing)
-   [Cost Calculator](/twitter-api-cost-calculator)
-   [Rate Limits](/twitter-api-rate-limits)
-   [MCP Server](/mcp)
-   [Integrations](/integrations)
-   [Language Clients](/sdk)
-   [Changelog](/changelog)
-   [Status](/status)

## Developers

-   [Documentation](https://docs.twitterapis.com)
-   [API Reference](https://docs.twitterapis.com/docs/reference/search/tweet-advanced-search)
-   [User Info](https://docs.twitterapis.com/docs/reference/user-reads/user-info)
-   [User Tweets](https://docs.twitterapis.com/docs/reference/user-reads/user-tweets)
-   [Advanced Search](https://docs.twitterapis.com/docs/reference/search/tweet-advanced-search)
-   [Verified Followers](https://docs.twitterapis.com/docs/reference/follower-graph/user-verified-followers)

## Resources / Compare

-   [Answers](/answers)
-   [Reviews](/reviews)
-   [Free Tools](/tools)
-   [Twitter ID Finder](/tools/twitter-id-finder)
-   [Get a Twitter API Key](/twitter-api-key)
-   [Official X API Comparison](/twitter-api-pricing)
-   [Twitter API Use Cases](/twitter-api-usecases)
-   [Twitter API Alternatives](/twitter-api-alternatives)
-   [Twitter Unofficial API](/twitter-unofficial-api)
-   [Twitter Free API](/twitter-free-api)
-   [TwitterAPIs vs twitterapi.io](/twitterapis-vs-twitterapi-io)
-   [TwitterAPIs vs GetXAPI](/twitterapis-vs-getxapi)
-   [TwitterAPIs vs TweetAPI](/twitterapis-vs-tweetapi)
-   [TwitterAPIs vs TwexAPI](/twitterapis-vs-twexapi)
-   [TwitterAPIs vs RapidAPI](/twitterapis-vs-rapidapi)

## Legal

-   [About](/about)
-   [Security](/security)
-   [Trust](/privacy-and-data-handling)
-   [Terms of Service](/terms-of-service)
-   [Affiliates](/affiliates)
-   [Contact](/contact)
-   [Jobs](/jobs)

© 2026 TwitterAPIs. All rights reserved.

TwitterAPIs is an independent third-party API for developers and researchers. Not affiliated with, endorsed by, or sponsored by X Corp.

All systems operational