Tweet Replies Scraper - No Login

Give it a tweet. Get back the replies X shows publicly on that tweet — the reply text, who wrote it, when, and how much engagement each reply got — as clean JSON.

No login. No cookies. No browser. No Twitter account.

Read this before you run it: coverage

X shows a logged-out visitor the top replies only. In every sample tested on 2026-09-04, that meant two to three replies per tweet — on a tweet with 23 replies and on a tweet with 167,872 replies alike.

The full conversation lives behind a GraphQL operation called TweetDetail, and that operation returns HTTP 404 to every guest request. Re-tested on 2026-09-04 with the query ID X's own live web app uses, alongside a control call that succeeded on the same guest token, so the 404 is not a stale identifier. It is not a matter of the right parameters or a fresher endpoint identifier: it is gated behind a signed-in session. Any cookie-free scraper claiming full reply threads is running logged-in accounts to get them.

So this actor gives you the replies X publishes, and it tells you the size of what it cannot see. Every row carries:

• focalReplyCountReported — the total reply count X itself reports for the tweet
• repliesVisibleToGuests — how many were actually retrievable

The coverage dataset view puts those two side by side. You are never left guessing whether you have the whole conversation.

If you need the full thread, you need a scraper that operates logged-in accounts, or the official paid X API. This README tells you that now, before you spend anything, rather than letting you find out from a dataset that looks thin.

What those replies are actually worth

They are not random. They are the replies X's own ranking picked as most relevant, which in practice means the highest-engagement replies on the tweet. For a lot of real work that is the useful subset:

• The top reply to a viral post is usually the one that shaped how people read it.
• Community notes, corrections and the "well actually" that got 100,000 likes surface here.
• The accounts that consistently land top replies on your competitor's posts are worth knowing about.

And each reply comes back complete, not as a snippet: full text, exact timestamp, likes, retweets, quotes, bookmarks, view count, its own sub-reply count, any attached media, the mentions and hashtags in it, and the replier's handle, display name, numeric user ID, profile URL, avatar, verified badge and follower/following/post counts.

Why the price still makes sense

$0.30 per 1,000 replies, the same on every Apify plan — free plan included. There is no free-tier multiplier here. At about three replies per tweet, scanning a thousand tweets costs roughly $0.90.

A tweet with no visible replies costs nothing. No row, no charge, and a FAILURES entry saying so. If half your input is single posts nobody replied to, you pay for the half that produced data.

Input

{
  "urls": [
    "https://x.com/jack/status/20",
    "https://x.com/elonmusk/status/1349129669258448897",
    "1519480761749016577"
  ],
  "minLikes": 100
}

Field	Type	Default	What it does
urls	array	—	Tweet URLs or bare numeric IDs. Aliases: url, tweetUrls, ids, tweetIds, startUrls.
maxItemsPerTarget	integer	100	Per-tweet ceiling. Well above what X exposes, so it only bites if X widens access.
maxItems	integer	none	Ceiling across the whole run. Aliases: maxResults, limit, maxReplies.
repliedAfter	string	—	Only replies on or after this. Alias: since.
repliedBefore	string	—	Only replies on or before this. Alias: until.
minLikes	integer	none	Drop replies below this like count. Filtered replies are not charged.

Full x.com URLs, legacy twitter.com URLs, /statuses/ URLs, URLs with tracking parameters, and bare numeric IDs all work, mixed freely in one list. Duplicate tweet IDs are collapsed before anything is fetched.

Dates accept YYYY-MM-DD, a full ISO timestamp, or a relative window like 7 days or 3 months. An unreadable date raises an error naming the field and echoing what you passed, rather than being silently dropped. A window where repliedAfter is later than repliedBefore stops the run immediately instead of working through your whole list to produce nothing.

Output

One row per reply.

Field	Notes
id	The reply's own tweet ID.
url	Direct link to the reply.
text	Full reply text, including the leading @mention.
createdAt	ISO 8601 UTC.
likeCount	Likes on the reply.
retweetCount	Retweets of the reply.
replyCount	Sub-replies to this reply.
authorHandle, authorName, authorId, authorUrl	The replier. authorId is the stable numeric X user ID.
authorProfileImageUrl	400x400 avatar.
tweetId, tweetUrl, tweetAuthorHandle	The tweet being replied to.
focalReplyCountReported	Total replies X reports on that tweet.
repliesVisibleToGuests	How many were actually retrievable.
scrapedAt	Fetch time.

All fields above were present on 100% of rows in the verification run. Where a value is genuinely unavailable it is null, never a fabricated 0.

Counters are normalised before they reach you: abbreviated display values become integers, and a negative count becomes null rather than being passed through, since a 32-bit overflow is not a measurement. createdAt is parsed from X's own timestamp format into ISO 8601, and an unreadable value becomes null instead of a 1970 epoch date that would slip past your date filter.

View counts are included. X began sending them to logged-out clients with the Sep 2026 rebuild of the signed-out page; where X omits one, the field is null rather than estimated.

How it works

A logged-out x.com status page ships the data the page renders from, inlined in the HTML. This actor fetches the page exactly as a browser would, reads that payload, and normalises it.

Until Aug 2026 the payload was a schema.org SocialMediaPosting block. In Sep 2026 X rebuilt its signed-out page and the replies moved into the router's dehydrated Relay store, which is what the actor reads today - it parses that payload rather than executing it, so a page from X can never run code inside the run. Reading the data layer instead of the rendered HTML means a CSS or component change does not break the actor; a change to the data layer itself does, which is exactly what happened in Aug 2026 and what this version fixes. No headless browser is launched; the actor is a plain HTTP client at 1 GB of memory, so platform compute is negligible next to the per-result price.

Bare IDs are fetched through x.com/i/status/<id>, which resolves correctly without needing to know the author's handle first. That saves you a lookup and saves the run a request.

Errors go where you can act on them

Nothing that failed is written into the dataset. It goes into the FAILURES key-value record:

{
  "actor": "Tweet Replies Scraper",
  "targetsRequested": 3,
  "resultsDelivered": 6,
  "resultsCharged": 6,
  "failureCount": 1,
  "failures": [
    {
      "target": "1755000000000000000",
      "error": "X shows no replies publicly on this tweet, although it reports 4 in total. Nothing was charged."
    }
  ],
  "notes": [
    "On 2 tweet(s) X reports more replies than it shows to a logged-out visitor. Compare focalReplyCountReported against repliesVisibleToGuests in each row to see the gap."
  ]
}

There are no {"noResults": true} sentinel objects in your dataset. A run that delivers nothing is marked FAILED, not quietly succeeded over an empty dataset, and you are charged nothing either way.

Pricing

$0.30 per 1,000 replies. Pay per result. No subscription. Same price on every Apify plan.

Replies	Cost	Roughly this many tweets
300	$0.09	100
3,000	$0.90	1,000
30,000	$9.00	10,000

Tweets with no visible replies, deleted tweets, malformed inputs and filtered-out replies all cost $0.00.

Typical uses

• Reaction sampling at scale. Run it over a few thousand posts from a brand, a category or an event and read the top reply on each. It is a fast, cheap read on how a message landed.
• Finding the loudest voices. The repliers dataset view lists the accounts writing top replies, with their user IDs. Feed those handles into the X Profile Scraper in this fleet to size them up.
• Correction and crisis monitoring. The reply that gets the most likes on a wrong claim is usually the correction. It is the one this actor returns.
• Competitive listening. Who reliably lands the top reply under your competitor's announcements, and what do they say.
• Sentiment sampling with honest error bars. Three top replies is a biased sample and you should treat it as one — but focalReplyCountReported tells you exactly how biased, which is more than most reply data comes with.

Limits worth knowing before you start

• Three replies per tweet, not the whole thread. Covered at the top. This is X's limit for logged-out clients, verified across sample tweets ranging from 23 to 167,872 replies.
• The visible replies are ranked by X, not chronological. They are the top replies, not the first ones.
• Nested sub-replies are not fetched. Each row reports its own replyCount, but the branch below it is not walked — X does not expose it publicly either.
• Deleted, protected and suspended-account tweets return nothing and are reported as failures rather than billed.
• No keyword search. This actor takes tweets, not queries. X blocks the search timeline for guests entirely.

Verified

Every endpoint, field and coverage figure in this README was tested live against X on 2026-09-04 with no cookies and no account, through residential IPs. The two-to-three reply ceiling and the TweetDetail 404 are measurements taken that day, not assumptions.

Related actors

• Tweet Scraper by URL or ID — the tweet itself with full metrics, $0.20/1k.
• X Profile Scraper - No Login — turn repliers into full profiles, $0.25/1k.
• X Profile Posts Scraper - No Cookies — an account's timeline, $0.30/1k.
• X Trends Scraper by Country — 62 countries and 400+ cities, $0.40/1k.

Same rules across all of them: one price on every plan, and nothing charged for nothing.