X Twitter Posts Search (Reposter Finder)

X Twitter Posts Search Scraper — Reposters and Influence

X Twitter Posts Search Scraper searches X (Twitter) by keyword, hashtag, profile or post URL and returns structured post data — text, media, engagement counts and author details — as typed JSON. For every post it keeps, it also pulls the accounts that reposted it, ranked by follower count, into a separate reposters dataset, with an audience-reach rollup written back onto the post row. Every response is structured JSON, ready to pass directly to an LLM, index into a vector store, or feed a monitoring pipeline. Search X for the posts that matter, then see exactly who amplified them.

What is X Twitter Posts Search Scraper?

X Twitter Posts Search Scraper is an Apify Actor that queries X's own search, profile-timeline and single-post surfaces and returns posts as structured JSON — then, for each post, fetches the accounts that reposted it and ranks them by follower count. That reposter lookup is what separates it from a plain posts-search scraper: instead of just counting reposts, it identifies who did the reposting and how much combined audience they carry.

Keyword and hashtag search, and the reposter/quote-amplifier lookups, require the caller's own X session cookies (authToken and ct0) — X answers anonymous callers on those surfaces with an empty HTTP 404. Profile timelines and single post URLs work without any cookies.

• 🎯 Six target types in one input list — keywords, X search syntax, hashtags, profile URLs/handles, and single post URLs
• 🔁 Reposter (retweeter) lookup per post, with follower count, verification, bio, location and account age
• 📣 An influence rollup on every post row — combined reposter reach, verified-reposter count, top follower count
• 💭 Optional quote-post amplifier collection, separate from plain reposts
• 🔎 Top vs Latest sort mode for keyword/hashtag search, plus a day- or hour-based time window applied to every target type
• ⏹️ A self-verifying "ranked early exit" that stops paging reposters once follower counts provably drop below your threshold

What data can you get with X Twitter Posts Search Scraper?

The Actor returns three result types: the post itself, the accounts that reposted it, and — optionally — the accounts that quote-posted it.

Result Type	Extracted Fields	Primary Use Case
Post	postId, postUrl, postText, timestamp, postedAt, conversationId, author (nested), media (nested), replyCount, quoteCount, repostCount, favouriteCount, viewCount, bookmarkCount, lang, isRetweet, repostedBy, targetType, targetInput, errorReason	Content and engagement analysis, brand-mention monitoring
Reposters (child dataset)	reposterId, reposterScreenName, reposterName, reposterProfileUrl, accountStatus, followersCount, friendsCount, statusesCount, favouritesCount, listedCount, mediaCount, isBlueVerified, accountCreatedAt, accountAgeDays, bio, location, websiteUrl, profileImageUrl, profileBannerUrl, pinnedPostId, professionalType, plus postId, postUrl, postAuthorScreenName, targetInput	Influencer identification, amplifier network mapping
Quote amplifiers (nested on the post row)	topQuoteAmplifiers[].screenName, .followersCount, .postUrl, .favouriteCount	Tracking commentary-driven amplification separately from plain reposts

Reposters and influence rollup

For every post kept, the Actor fetches X's Retweeters list and writes each account into a separate child dataset — not just a count. Each reposter row carries follower count, X Blue verification, account age, bio, location and profile links, so you can identify who amplified a post, not just how many times. The post row itself carries a rollup so you never have to join the two datasets just to answer "how big was the audience this reached":

{
  "repostFetchStatus": "ok",
  "repostersReturned": 100,
  "reposterAudienceReach": 4812330,
  "reposterVerifiedCount": 12,
  "reposterTopFollowerCount": 892100,
  "reposterUnavailableCount": 1,
  "reposterRankingObserved": "descending",
  "reposterEarlyExit": false,
  "reposterPagesFetched": 1,
  "reposterStopReason": "completed",
  "topReposters": [
    {
      "screenName": "spacenews_daily",
      "name": "Space News Daily",
      "followersCount": 892100,
      "isBlueVerified": true,
      "profileUrl": "https://x.com/spacenews_daily"
    }
  ]
}

Because X ranks the Retweeters surface roughly by follower count, topReposters (the top 10 by followers) surfaces your biggest amplifiers without any client-side sorting.

Quote amplifiers

Quote-posts — reposts with added commentary — are a separate, optional surface (includeQuoteAmplifiers). X caps this surface at roughly 40 quote posts per post regardless of the real quote count, so it's off by default and spends the scarcer search request budget when enabled. The top 10 by follower count are written to topQuoteAmplifiers on the post row, each carrying screenName, followersCount, postUrl and favouriteCount.

Why not build this yourself?

X has no public search API that an anonymous script can call for free — keyword search, profile timelines and the Retweeters/quote-amplifier lists all run through X's internal GraphQL surface, the same one the x.com web app uses. Building and maintaining a caller for that surface is the real cost of doing this yourself.

Every GraphQL operation needs a queryId that X rotates without notice, embedded either in the site's main.<hash>.js bundle or in a lazily loaded webpack chunk — Retweeters specifically ships in a chunk, not in main.js, so it has to be resolved by walking the page's webpack id→name/hash manifest rather than a simple regex over one file. This Actor discovers every queryId live at the start of each run, and self-heals mid-run: a response that comes back HTTP 404 with a zero-byte body is treated as a dead query id, triggering an automatic re-harvest and retry rather than a silent zero-row result.

Two of X's own surfaces also carry undocumented traps that look like bugs until you've hit them: SearchTimeline answers a GET request with an empty 404 (it must be POSTed), and the Retweeters timeline emits user-<id> entry ids instead of the tweet- prefix every other timeline uses — a parser written against one surface silently returns zero rows on the other. On top of that, X's two user-object schemas (core.screen_name vs legacy.screen_name) are both live simultaneously across different surfaces, so a reposter reader has to check both or drop accounts at random. Then there's the access layer: keyword search and reposter lists are login-walled, so a caller needs a real X session, real block detection (an HTTP 200 with a missing result container is still a block, not a success), retry and backoff logic, and — per the Actor's own published account budgets — a request pace that respects roughly 500 reposter calls and 187 search calls per 15 minutes per X account before hitting a rate-limit wall.

What is the difference between a posts search scraper and a reposter finder?

A posts search scraper answers "what was posted." A reposter finder answers "who spread it, and how far." Most X/Twitter scrapers, including the ones checked for this README, return a repostCount — a single number — and stop there. That number tells you a post was reposted 400 times; it does not tell you whether those 400 reposts came from a handful of large accounts or thousands of small ones, and it cannot name a single amplifier.

X Twitter Posts Search Scraper returns both objects. The post row carries the same engagement counts any posts-search scraper returns (repostCount, favouriteCount, replyCount, quoteCount), plus a rollup (reposterAudienceReach, reposterVerifiedCount, topReposters) computed from a second, separate query against X's Retweeters list — written to its own child dataset, one row per reposting account. If your workflow only needs post content and counts, ignore the reposter fields and includeReposters costs nothing extra to leave off. If you need to identify who is amplifying a message — for influencer discovery, coordinated-activity checks, or PR monitoring — the reposter dataset is the part a plain search scraper can't give you.

How to scrape X posts and their reposters with X Twitter Posts Search Scraper?

1. Open X Twitter Posts Search Scraper on the Apify Store and click Try for free
2. Add one or more entries to startUrls — keywords, @handles, profile URLs, X search URLs, hashtags, or single post URLs
3. For keyword/hashtag search and reposter lookups, expand X session cookies and paste your own authToken and ct0 cookie values from a logged-in x.com session
4. Set searchType (Top or Latest), maxTweets, and the reposter settings you want — includeReposters, maxRepostersPerPost, minReposterFollowers
5. Click Start, then download the post dataset and the named reposters dataset as JSON, CSV or Excel — or read both through the Apify API

How to run multiple targets in one job

startUrls is a list — mix keywords, handles, search URLs and post URLs freely in the same run, one row per target. Every target shares the same maxTweets, searchType, time window and reposter settings for that run; each target's kept posts and reposters are tagged with targetType and targetInput so you can tell which target produced which row after the fact.

⬇️ Input

startUrls is the only field with no default — everything else has a working default so a first run only needs a target list and, for search or reposters, your two X cookies.

Parameter	Required	Type	Description	Example Value
startUrls	Yes	array	One row per target: keyword(s), X search syntax (search: nasa min_retweets:500), an X search URL, a hashtag URL or #tag, a handle/profile URL, or a single post URL. Keyword/search/hashtag targets need cookies; profile and post-URL targets do not. X app pages (/explore, /i/…, /home) are skipped — they have no scrapable timeline.	["@NASA", "climate change"]
maxTweets	No	integer	Cap on posts collected per target. Minimum 1, maximum 10000, default 10. Every kept post can trigger one or more reposter calls, so this is also your reposter-call budget multiplier.	10
searchType	Yes	string	Sort mode for keyword/hashtag search only: "top" (popular & relevant — best for finding posts that got reposted) or "latest" (newest first — best with a time window for live monitoring). Profile timelines have no sort parameter and are always reverse-chronological regardless of this setting. Default "top".	"top"
timeWindow	No	integer	Keep only posts newer than N days (UTC). Minimum 1. Applied to every target type — search, profiles and post URLs alike. Leave empty to collect up to maxTweets regardless of date.	7
timeWindowHours	No	integer	Keep only posts newer than N hours (UTC). Minimum 1. Applied to every target type. Takes precedence over timeWindow if both are set.	4
authToken	No	string (secret)	The auth_token cookie from your logged-in x.com session. Find it via DevTools → Application → Cookies → https://x.com. Stored encrypted, never written to the dataset or the run log. X's rate-limit budget is shared across every run using the same X account.	(paste your cookie value)
ct0	No	string (secret)	The ct0 cookie (X's CSRF token) from the same logged-in session as authToken. Both cookies must come from the same session or X rejects the request. Stored encrypted, never written to the dataset or the run log.	(paste your cookie value)
includeReposters	No	boolean	On: for every post kept, fetch the accounts that reposted it. Off: posts only — each row reports repostFetchStatus: "disabled". Posts with a repost count of 0 are skipped automatically. Default true.	true
maxRepostersPerPost	No	integer	Cap on reposters collected per post. Minimum 0, maximum 5000, default 100. X returns 100 accounts per call regardless of the requested count (a hard server clamp), so 100 = 1 call, 500 = 5 calls.	100
minReposterFollowers	No	integer	Keep only reposters with at least N followers. Minimum 0, default 0 (keep everyone). Pairs with rankedEarlyExit.	10000
rankedEarlyExit	No	boolean	On: once minReposterFollowers is set, stop paging a post once returned accounts fall below it — self-verifying, so it only arms when the post's follower ordering is genuinely descending, and still waits 2 consecutive below-threshold pages before stopping. Off: always page to maxRepostersPerPost. Default true.	true
includeQuoteAmplifiers	No	boolean	On: also fetch accounts that quote-posted the post. X caps this surface at roughly 40 quote posts per post no matter the real quote count, and it spends the scarcer search-request budget — off by default. Default false.	false
maxQuoteAmplifiersPerPost	No	integer	Cap on quote posts collected per post. Minimum 0, maximum 40, default 40. X's own ceiling is ~40, so higher values change nothing.	40
reposterDatasetName	No	string	Name for the separate reposters dataset, so post rows stay clean. Leave empty to auto-name it x-reposters-<runId>. Set a fixed name to append every run's reposters into one growing dataset.	"nasa-reposters"
proxyConfiguration	No	object	Apify Proxy settings. Off = direct connection. On = Apify Proxy with your chosen groups. RESIDENTIAL is prefilled as the safest default; datacenter groups were also measured returning HTTP 200 on X.	{"useApifyProxy": true, "apifyProxyGroups": ["RESIDENTIAL"]}

Example input

{
  "startUrls": ["@NASA", "climate change", "https://x.com/NASA/status/1234567890123456789"],
  "maxTweets": 20,
  "searchType": "top",
  "timeWindow": 7,
  "authToken": "<your auth_token cookie>",
  "ct0": "<your ct0 cookie>",
  "includeReposters": true,
  "maxRepostersPerPost": 100,
  "minReposterFollowers": 5000,
  "rankedEarlyExit": true,
  "includeQuoteAmplifiers": false,
  "proxyConfiguration": { "useApifyProxy": true, "apifyProxyGroups": ["RESIDENTIAL"] }
}

Common pitfall: authToken and ct0 must come from the same logged-in x.com browser session — pasting a ct0 from one login and an auth_token from another gets rejected by X, not silently ignored. Without both cookies, keyword/hashtag targets fail with errorReason: "login_required" while profile and post-URL targets still run normally.

⬆️ Output

Results are typed, normalized JSON with a consistent schema across runs. Post rows land in the run's default dataset; reposter rows land in a separate named dataset (reposterDatasetName, or x-reposters-<runId> if left blank). Export either as JSON, CSV, Excel, or read them through the Apify API.

Scraped results

A successful post row:

[
  {
    "postText": "NASA's Perseverance rover just captured a stunning new panorama of the Jezero Crater delta.",
    "postUrl": "https://x.com/NASA/status/1810234567890123456",
    "timestamp": 1721923200000,
    "postedAt": "2024-07-25T14:00:00Z",
    "conversationId": "1810234567890123456",
    "postId": "1810234567890123456",
    "media": [
      { "mediaUrlHttps": "https://pbs.twimg.com/media/example1.jpg", "type": "photo", "id": "1810234500000000001" }
    ],
    "author": {
      "name": "NASA",
      "screenName": "NASA",
      "followersCount": 96200000,
      "favouritesCount": 8400,
      "friendsCount": 320,
      "description": "Explore the universe and discover our home planet."
    },
    "replyCount": 812,
    "quoteCount": 140,
    "repostCount": 6420,
    "favouriteCount": 41200,
    "viewCount": 3820000,
    "bookmarkCount": 2210,
    "lang": "en",
    "isRetweet": false,
    "repostedBy": null,
    "repostFetchStatus": "ok",
    "repostersReturned": 100,
    "reposterAudienceReach": 4812330,
    "reposterVerifiedCount": 12,
    "reposterTopFollowerCount": 892100,
    "reposterUnavailableCount": 1,
    "reposterRankingObserved": "descending",
    "reposterEarlyExit": false,
    "reposterPagesFetched": 1,
    "reposterStopReason": "completed",
    "topReposters": [
      { "screenName": "spacenews_daily", "name": "Space News Daily", "followersCount": 892100, "isBlueVerified": true, "profileUrl": "https://x.com/spacenews_daily" }
    ],
    "quoteAmplifiersReturned": 0,
    "quoteAmplifierStatus": "disabled",
    "topQuoteAmplifiers": [],
    "targetType": "user",
    "targetInput": "NASA",
    "errorReason": null
  },
  {
    "postText": "Full mission timeline for the upcoming Europa Clipper launch window.",
    "postUrl": "https://x.com/NASA/status/1810234567890123457",
    "timestamp": 1721836800000,
    "postedAt": "2024-07-24T14:00:00Z",
    "conversationId": "1810234567890123457",
    "postId": "1810234567890123457",
    "media": [],
    "author": {
      "name": "NASA",
      "screenName": "NASA",
      "followersCount": 96200000,
      "favouritesCount": 8400,
      "friendsCount": 320,
      "description": "Explore the universe and discover our home planet."
    },
    "replyCount": 203,
    "quoteCount": 18,
    "repostCount": 0,
    "favouriteCount": 5100,
    "viewCount": 610000,
    "bookmarkCount": 340,
    "lang": "en",
    "isRetweet": false,
    "repostedBy": null,
    "repostFetchStatus": "no_reposts",
    "repostersReturned": 0,
    "reposterAudienceReach": 0,
    "reposterVerifiedCount": 0,
    "reposterTopFollowerCount": null,
    "reposterUnavailableCount": 0,
    "reposterRankingObserved": "n/a",
    "reposterEarlyExit": false,
    "reposterPagesFetched": 0,
    "reposterStopReason": "no_reposts",
    "topReposters": [],
    "quoteAmplifiersReturned": 0,
    "quoteAmplifierStatus": "disabled",
    "topQuoteAmplifiers": [],
    "targetType": "user",
    "targetInput": "NASA",
    "errorReason": null
  },
  {
    "postText": null,
    "postUrl": null,
    "timestamp": null,
    "conversationId": null,
    "postId": null,
    "media": [],
    "author": null,
    "replyCount": null,
    "quoteCount": null,
    "repostCount": null,
    "favouriteCount": null,
    "repostFetchStatus": "login_required",
    "repostersReturned": 0,
    "reposterAudienceReach": 0,
    "reposterVerifiedCount": 0,
    "reposterTopFollowerCount": null,
    "reposterUnavailableCount": 0,
    "reposterRankingObserved": "n/a",
    "reposterEarlyExit": false,
    "reposterPagesFetched": 0,
    "reposterStopReason": "login_required",
    "topReposters": [],
    "quoteAmplifiersReturned": 0,
    "quoteAmplifierStatus": "skipped",
    "topQuoteAmplifiers": [],
    "targetType": "search",
    "targetInput": "nasa min_retweets:500",
    "errorReason": "login_required"
  }
]

The third row above is a target-failure accounting row — it is pushed so a run never finishes green with silently zero rows, but it is not charged. Every row_result pay-per-event charge is tied to a real post row; a target that fails (no cookies for a search target, X blocking a target, a resolved-then-vanished profile) writes one uncharged row with errorReason set and every base field null/0 instead. Filter charged rows from accounting rows with item.errorReason == null.

Reposter dataset (child dataset, one row per reposting account):

[
  {
    "reposterId": "1502938471029384710",
    "reposterScreenName": "spacenews_daily",
    "reposterName": "Space News Daily",
    "reposterProfileUrl": "https://x.com/spacenews_daily",
    "accountStatus": "active",
    "followersCount": 892100,
    "friendsCount": 412,
    "statusesCount": 88210,
    "favouritesCount": 21400,
    "listedCount": 3100,
    "mediaCount": 6200,
    "isBlueVerified": true,
    "accountCreatedAt": "2012-03-14T09:12:00Z",
    "accountAgeDays": 5247,
    "bio": "Breaking space and astronomy news, 24/7.",
    "location": "Houston, TX",
    "websiteUrl": "https://spacenewsdaily.example",
    "profileImageUrl": "https://pbs.twimg.com/profile_images/example/avatar.jpg",
    "profileBannerUrl": "https://pbs.twimg.com/profile_banners/example/banner.jpg",
    "pinnedPostId": "1809000000000000001",
    "professionalType": null,
    "postId": "1810234567890123456",
    "postUrl": "https://x.com/NASA/status/1810234567890123456",
    "postAuthorScreenName": "NASA",
    "targetInput": "NASA"
  },
  {
    "reposterId": "1893746501283746501",
    "reposterScreenName": "orbital_watch",
    "reposterName": "Orbital Watch",
    "reposterProfileUrl": "https://x.com/orbital_watch",
    "accountStatus": "active",
    "followersCount": 41300,
    "friendsCount": 890,
    "statusesCount": 15200,
    "favouritesCount": 9800,
    "listedCount": 210,
    "mediaCount": 1900,
    "isBlueVerified": false,
    "accountCreatedAt": "2019-08-02T17:40:00Z",
    "accountAgeDays": 2549,
    "bio": "Tracking rockets, satellites and Mars missions.",
    "location": null,
    "websiteUrl": null,
    "profileImageUrl": "https://pbs.twimg.com/profile_images/example2/avatar.jpg",
    "profileBannerUrl": null,
    "pinnedPostId": null,
    "professionalType": null,
    "postId": "1810234567890123456",
    "postUrl": "https://x.com/NASA/status/1810234567890123456",
    "postAuthorScreenName": "NASA",
    "targetInput": "NASA"
  },
  {
    "postId": "1810234567890123456",
    "postUrl": "https://x.com/NASA/status/1810234567890123456",
    "accountStatus": "unavailable",
    "unavailableCount": 1,
    "note": "X returns suspended/deleted reposters as anonymous nodes carrying no id, handle or name — they can be counted, never identified.",
    "targetInput": "NASA"
  }
]

Reposter dataset rows are never charged — only the row_result event on post rows carries a pay-per-event charge.

How can I use the data extracted with X Twitter Posts Search Scraper?

• PR and communications teams: search for a campaign or brand keyword, sort by topReposters per post, and identify the specific accounts driving reach before deciding who to engage or thank directly.
• Influencer and partnerships teams: run includeReposters against a niche keyword or hashtag over several runs, and build a shortlist of accounts that repeatedly appear in topReposters across posts — these are working amplifiers, not just followers.
• AI engineers and LLM developers: an agent issues a query against startUrls, receives structured post and reposter JSON back, and grounds an answer about "who is amplifying X" without hallucinating account names.
• Trust & safety / misinformation researchers: compare reposterRankingObserved and reposterAudienceReach across a set of posts on the same topic to spot posts whose repost activity is concentrated in a small number of large accounts versus organically spread.

How do you monitor repost activity over time?

Repost monitoring means re-running the same target set on a schedule and diffing the reposter rollup between runs to catch amplification as it happens, rather than reading a single static snapshot.

Between runs, the fields that move are repostCount and repostersReturned (raw volume), reposterAudienceReach (how much combined follower reach has now seen the post), reposterVerifiedCount (whether larger, verified accounts have picked it up), and the contents of topReposters itself — a new screen name entering the top 10 is a concrete, attributable signal, unlike a bare count going up.

A practical loop: schedule a run across a fixed keyword or handle set with searchType: "latest" and a timeWindowHours window, keep reposterDatasetName fixed so every run's reposters append to one growing dataset, then compare each post's reposterAudienceReach and topReposters against the previous run's row for the same postId. A jump in reposterAudienceReach or a new high-follower name in topReposters is the alert condition; everything else is noise.

X Twitter Posts Search Scraper has no built-in scheduler of its own — set this up with an Apify Schedule on the Actor, which triggers a run on the interval you set and lets you attach a webhook on run completion for downstream delivery.

Integrate X Twitter Posts Search Scraper and automate your workflow

X Twitter Posts Search Scraper works with any language or tool that can send an HTTP request, since it runs on the Apify platform.

REST API with Python

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run = client.actor("<YOUR_USERNAME>/x-twitter-posts-search-reposter-finder").call(run_input={
    "startUrls": ["@NASA", "climate change"],
    "searchType": "top",
    "maxTweets": 20,
    "authToken": "<your auth_token cookie>",
    "ct0": "<your ct0 cookie>",
    "includeReposters": True,
    "minReposterFollowers": 5000,
})

for post in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(post["postUrl"], post["repostCount"], post["reposterAudienceReach"])

Works in Go, Ruby, Node.js, cURL — any language that can make an HTTP request. Reposter rows live in the separate named dataset (reposterDatasetName, or x-reposters-<runId>) — open it from the run's Storage tab in the Apify Console, or resolve it by name through the Apify client's dataset collection.

Scheduled monitoring and delivery

X Twitter Posts Search Scraper has no webhook or push delivery of its own — set an Apify Schedule to trigger repeat runs, and attach an Apify webhook on run completion to push a notification or payload to your own endpoint once results land in the dataset.

Is it legal to scrape X posts and reposter data?

Yes — X Twitter Posts Search Scraper collects only what any logged-in or, for profile and post-URL targets, anonymous visitor can already see on x.com; it does not access private accounts or bypass any access control.

Reposter data — screen names, bios, follower counts, locations and account age — is personal data about identifiable individuals, so data protection regimes like GDPR (EU) and the CCPA (California) can apply to how you store, use and retain it, not just to how it was collected. Courts have generally treated scraping of data that is publicly accessible without authentication as distinct from unauthorized computer access — see hiQ Labs v. LinkedIn, 9th Cir. (2019) — but that case concerns access, not your downstream data-protection obligations once you hold the data.

Scraping for one-off research or monitoring carries a different risk profile than scraping to train an AI model or build a resellable database of X accounts. Consult your legal team for commercial use cases involving bulk storage or reuse of reposter profile data.

❓ Frequently asked questions

Does X Twitter Posts Search Scraper find who reposted a post?

Yes. For every post it keeps (when includeReposters is on and repost count is above 0), it fetches X's Retweeters list and writes each account to a separate child dataset, with a rollup — reposterAudienceReach, reposterVerifiedCount, reposterTopFollowerCount, topReposters — merged onto the post row itself. If X's session cookies aren't supplied, reposter fetching is skipped and the row reports repostFetchStatus: "login_required" instead of failing the run.

What happens if a post has zero reposts?

It's detected and skipped automatically before any reposter call is made — repostFetchStatus is set to "no_reposts" and every reposter field returns 0 or null. No reposter budget is spent chasing posts that were never reposted.

How many posts does X Twitter Posts Search Scraper return per search?

Up to maxTweets per target (default 10, maximum 10000). Internally the Actor over-fetches roughly 3× that number of raw posts per target to absorb duplicates and time-window filtering, then stops once maxTweets posts have actually been kept — so the raw-fetch count in the run log and the saved row count are expected to differ.

Does X Twitter Posts Search Scraper support Top vs Latest sorting?

Yes, via searchType, but only for keyword and hashtag search — X's profile-timeline endpoint has no sort parameter, so profile targets are always reverse-chronological regardless of this setting. "top" surfaces popular/relevant posts (best for finding posts that actually got reposted); "latest" returns newest first, best paired with timeWindow/timeWindowHours for live monitoring.

Can I filter reposters by follower count?

Yes. minReposterFollowers drops reposters below a follower threshold. Because X returns the Retweeters list roughly follower-descending on posts whose pages come back full, pairing this with rankedEarlyExit lets the Actor stop paging a post once it can prove the remaining pages are all below your threshold — the run logs reposterRankingObserved and reposterEarlyExit on every post so you can audit exactly when this happened.

How does X Twitter Posts Search Scraper handle X's anti-bot measures?

Every response is checked against three conditions — HTTP 200, a result URL still on an x.com GraphQL path, and the expected JSON container actually present — before it's treated as a real success; anything else raises a typed failure rather than a silent empty result. 5xx responses and network errors are retried with exponential backoff (up to 3 attempts), HTTP 429 waits and retries once, and a GraphQL queryId that comes back dead (HTTP 404 with a zero-byte body) triggers an automatic live re-discovery and retry rather than failing the target outright.

Can I also collect quote-post amplifiers, not just reposts?

Yes, with includeQuoteAmplifiers (off by default). It's a separate surface from plain reposts — X caps it at roughly 40 quote posts per post regardless of the real quote count — and results land in topQuoteAmplifiers on the post row (top 10 by follower count), each with screenName, followersCount, postUrl and favouriteCount.

How do I monitor a post's repost activity over time?

Schedule repeat runs against the same target set with a fixed reposterDatasetName, then diff reposterAudienceReach, reposterVerifiedCount and topReposters for the same postId between runs. See "How do you monitor repost activity over time?" above for the full loop.

Does X Twitter Posts Search Scraper work with Claude, ChatGPT and AI agent frameworks?

It's callable as a standard HTTP endpoint through the Apify API, so any agent framework that can make a request — LangChain, CrewAI, a custom tool definition — can invoke it and receive typed post and reposter JSON directly, enabling a grounded agent that retrieves live amplification data before answering.

How does X Twitter Posts Search Scraper compare to other X/Twitter scrapers?

Checked on the Apify Store on 2026-07-26, scraper_one/x-posts-search and the near-identical listings from scraper-engine/x-twitter-posts-search and scrapebase/x-twitter-posts-search return post text, media, author details and engagement counts — none of the three documents a reposter, retweeter or quote-amplifier dataset, or any per-post influence rollup. X Twitter Posts Search Scraper's difference is that second dataset: identified reposting accounts with follower counts and verification, plus the audience-reach rollup computed from them, alongside the same post-level search coverage.

Can I use X Twitter Posts Search Scraper without managing proxies or platform credentials?

You never need to set up a proxy account — Apify Proxy is built in and RESIDENTIAL is prefilled. What you do need to supply yourself, for keyword/hashtag search and any reposter or quote-amplifier lookup, are your own X authToken and ct0 session cookies; profile-timeline and single post-URL targets need neither.

🔗 Related scrapers

Scraper Name	What it extracts
Twitter X Posts Scraper With Contact Links	Post search with contact-link extraction from author bios
Twitter X Reply Scraper — Conversation Engagement Analytics	Replies to a post, with conversation engagement analytics
Twitter Trends Scraper With Rank History & Staying Power	Trending topics, with rank history over time

💬 Your feedback

Found a bug, or need a reposter or post field that X exposes but this Actor doesn't return yet? Open an issue on the Actor's Issues tab on Apify — field requests backed by a sample post URL are the fastest to act on.