Best Twitter (X) scrapers on Apify, tested: six tweet scrapers, the same three jobs, every byte kept

1. How we chose the six tweet scrapers

The census behind this site tracks every X (Twitter) actor on the Apify Store; 53 of them have at least 30 monthly users. We removed everything that is not a tweet scraper: profile and user scrapers, follower scrapers, trend scrapers, list scrapers, reply-only scrapers, a video downloader. Fifteen remained.

Ranking the fifteen by monthly users and taking the top six would put four actors from two publishers on the page and tell you little. We took one actor per reason instead.

Census snapshot of 2026-09-08. “6-week change” compares monthly users on 28 July and 8 September. “First published” is the actor’s creation date from the Apify API. Success is the store’s public 30-day run statistic. Listed price is the primary pay-per-event price shown on the store listing.

Two of the six share a name

Since 10 August the listings of xquik/x-tweet-scraper and scrape.badger/twitter-tweets-scraper carry the same title, character for character: X Tweet Scraper | $0.15/1K Tweets | Pay-Per-Result. scrape.badger’s is the older listing (May 2025 against March 2026). Our title history starts on 24 July, so we cannot say which wording came first. On 24 July xquik’s title still read From $0.15/1K Tweets | Pay-Per Result; it changed on 31 July and again on 10 August and arrived at the identical string. We report this because a buyer scanning the store sees two identical names and has no way to tell them apart. The rest of this page is one way.

Who we left out, and why

• api-ninja/x-twitter-advanced-search — 398 users, rated 4.86 from 45 reviews, but $0.015 per tweet: 100× the cheapest actor here. It is a search-only actor and deserves its own test at its own price point.
• scraper_one/x-profile-posts-scraper + x-posts-search — 417 and 313 users. The publisher splits profile posts and search into two actors; you would need both for our three jobs.
• altimis/scweet — 192 users. It entered our candidate list only on the latest snapshot, so we have no six-week history for it.
• automation-lab/twitter-scraper — 145 users, 92.6% success, down from 194 users six weeks ago.
• maximedupre/twitter-scraper — 83 users; its 30-day success rate swung from 50% to 94% inside the six-week window.
• scrapesmith, igolaizola, fastcrawler — 69, 50 and 30 users; the last two run at 87% and 90% success.

2. What we asked each scraper to do

Three jobs, the same for everyone.

1. Keyword search. The phrase web scraping, newest first, 100 tweets.
2. Profile timeline. The 50 newest posts by @apify.
3. Single-tweet lookup. Two tweets by id: a post with an image and some engagement, and a long-form post of 1,334 characters.

Rules

• We set only the query, the sort (Latest), the item cap and the handle or id. Everything else stayed at the actor’s documented default or console prefill. Where an actor’s console prefills an output shape (xquik: rich, camelCase, flat), we kept the prefill.
• Two actors have no profile mode. kaitoeasyapi and scrape.badger ran the profile job as a search for from:apify, which is what their READMEs suggest. Section 5 shows what that does to the result.
• All twelve search and profile runs were started inside the same second (22:13:48 UTC, 8 September 2026) from one Apify account on the Starter plan, through the API, with each actor’s default memory. The lookups ran about ten minutes later.
• One run per job per actor. No retries. We kept whatever came back.
• Costs are read from the run object after charges settled. Durations are the platform’s own startedAt to finishedAt, so they include the actor’s cold start.

What we expected back

A tweet record with, at minimum: Tweet id, Tweet URL, Text, Created at, Language, Author handle, Author name, Author id, Author followers, Likes, Retweets, Replies, Quotes, Views, Bookmarks, Reply flag, Retweet flag, Quote flag, Conversation id, Media, Links, Hashtags, Long-form flag, Source app. Section 7 shows who returns which.

{
 "searchTerms": [
  "web scraping"
 ],
 "sort": "Latest",
 "maxItems": 100
}

{
 "twitterContent": "web scraping",
 "queryType": "Latest",
 "maxItems": 100
}

{
 "searchTerms": [
  "web scraping"
 ],
 "sort": "Latest",
 "maxItems": 100
}

{
 "mode": "search",
 "searchTerms": [
  "web scraping"
 ],
 "queryType": "Latest",
 "maxItems": 100,
 "outputVariant": "rich",
 "fieldStyle": "camelCase",
 "outputPreset": "flat"
}

{
 "query": "web scraping",
 "search_type": "Latest",
 "max_posts": 100
}

{
 "mode": "Advanced Search",
 "query": "web scraping",
 "query_type": "Latest",
 "max_results": 100
}

{
 "twitterHandles": [
  "apify"
 ],
 "maxItems": 50
}

{
 "twitterContent": "from:apify",
 "queryType": "Latest",
 "maxItems": 50
}

{
 "twitterHandles": [
  "apify"
 ],
 "maxItems": 50
}

{
 "mode": "profileTweets",
 "twitterHandles": [
  "apify"
 ],
 "maxItems": 50,
 "outputVariant": "rich",
 "fieldStyle": "camelCase",
 "outputPreset": "flat"
}

{
 "username": "apify",
 "max_posts": 50
}

{
 "mode": "Advanced Search",
 "query": "from:apify",
 "query_type": "Latest",
 "max_results": 50
}

{
 "startUrls": [
  "https://x.com/apify/status/2095479050911309827"
 ],
 "maxItems": 1
}

{
 "tweetIDs": [
  "2095479050911309827"
 ],
 "maxItems": 1
}

{
 "startUrls": [
  "https://x.com/apify/status/2095479050911309827"
 ],
 "maxItems": 1
}

{
 "mode": "tweet",
 "startUrls": [
  "https://x.com/apify/status/2095479050911309827"
 ],
 "maxItems": 1,
 "outputVariant": "rich",
 "fieldStyle": "camelCase",
 "outputPreset": "flat"
}

{
 "lookup_post_ids": [
  "2095479050911309827"
 ],
 "max_posts": 1
}

{
 "mode": "Get Tweet by ID",
 "id": "2095479050911309827",
 "max_results": 1
}

{
 "startUrls": [
  "https://x.com/i/status/2096838373524812149"
 ],
 "maxItems": 1
}

{
 "tweetIDs": [
  "2096838373524812149"
 ],
 "maxItems": 1
}

{
 "startUrls": [
  "https://x.com/i/status/2096838373524812149"
 ],
 "maxItems": 1
}

{
 "mode": "tweet",
 "startUrls": [
  "https://x.com/i/status/2096838373524812149"
 ],
 "maxItems": 1,
 "outputVariant": "rich",
 "fieldStyle": "camelCase",
 "outputPreset": "flat"
}

{
 "lookup_post_ids": [
  "2096838373524812149"
 ],
 "max_posts": 1
}

{
 "mode": "Get Tweet by ID",
 "id": "2096838373524812149",
 "max_results": 1
}

3. Results at a glance

Every run finished with status SUCCEEDED. Total charged for all 24 runs: $0.36.

Keyword search: 100 tweets for “web scraping”

Profile timeline: 50 newest posts by @apify

Single tweet, the one with an image

Single tweet, the long-form one

“Charged per row” is the per-event price the platform applied to our run, which is not always the listed price (section 9). “Platform usage” says who pays compute and storage for the run: for five actors the publisher absorbs it, for xquik the user pays it on top of the per-tweet price. “Fields / row” is the average number of top-level keys per record.

4. Scraping tweets by keyword: the same 100 tweets, different text and different bills

All six actors returned the same tweets. The union of the six result sets is 101 ids; 99 of them appear in all six outputs, and no id appears in only one. The newest tweet is the same across all six (21:11:54 UTC, 62 minutes before the runs). View counts are identical for 100 of 101 shared tweets. Whatever these actors do behind the scenes, they read the same source at the same moment, and on this job retrieval is not where they differ.

Where they differ is the text. X allows posts far beyond 280 characters (long-form, or “note” tweets). 25 of the 100 tweets in this sample are long-form. Four actors return them whole. apidojo’s two actors return the first ~280 characters and stop, on 24 of the 25.

“In full” means the text is at least 95% as long as the longest version any actor returned for the same id. The long-form set is the 25 ids xquik flags as isNoteTweet; the other actors do not flag them, but four of them return the same 1,000–2,000-character bodies.

Speed ran from 15 s (scrape.badger) to 34 s (xquik) for the same 100 tweets. Price per 1,000 ran from $0.14 (scrape.badger) to $0.40 (both apidojo actors). Records ran from 1.9 KB (danek) to 6.1 KB (xquik) each; the difference is nested author objects, entity lists and, in xquik’s case, about thirty flattened author* fields per row.

5. Profile timeline: “the 50 newest posts by @apify” means five different things

This is the job where the six stop agreeing. The union of the six outputs is 101 distinct posts; only 14 of them appear in all six, and 22 appear in exactly one.

Retweets are rows whose text starts with “RT @”. Replies use the actor’s own flag; * marks actors without a reply flag, where we counted texts that start with “@”. “Sorted newest-first” is the share of consecutive rows in descending date order. Overlap is the number of ids in common with apidojo/tweet-scraper’s 50.

• apidojo V2 and Unlimited return the account’s timeline as X shows it: original posts, 9 retweets and 16 replies, with the pinned post included (V2 flags it; Unlimited dropped it). The rows are not in date order: the first nine descend from 8 September to 4 September, then the list jumps back to 8 September and starts again, which looks like two fetches concatenated. Sort before you use it.
• xquik in profileTweets mode removes replies by design and keeps retweets, so its 50 reach further back (to 12 August). It is the only actor with 0 replies. It is also the only actor that does not mark retweets and does not attach the original post: 10 of its 14 retweets arrive as 140-character stubs ending in “…”, with no way to recover the full text from the record.
• danek returns nearly the same set as apidojo (48 of 50 in common), attaches the original post to every retweet, and finished in 9 seconds. It also returned two posts twice.
• kaitoeasyapi and scrape.badger have no profile mode, so from:apify is a search. Search excludes retweets and includes every reply, so their “timeline” is 45 and 36 replies out of 60 and 50 rows, reaches back only to 1–2 September, and has 25 and 22 posts in common with the timeline actors. kaitoeasyapi also returned 60 rows for a cap of 50 and billed 60; its schema warns that “the final response may slightly exceed the specified max_items”.

None of these is wrong. They are different definitions of a profile pull. If you need what a visitor sees on the profile page, use a timeline actor and sort. If you need only original posts, xquik’s mode does that in one call. If you need replies, the two search-based actors give you mostly that.

6. Single-tweet lookup: one id, six answers

• The long-form post is 1,334 characters. Four actors returned all of it. apidojo V2 and Unlimited returned 277 characters, the same cut as in the search job. This is a direct lookup of one id, so it is not a paging artefact; the actors do not read the long-form body.
• kaitoeasyapi returned 15 rows for one tweet and billed 15. One row is the tweet. The other fourteen are of type mock_tweet with id −1 and this text: From KaitoEasyAPI, a reminder: Our API pricing is based on the volume of data returned. However, to ensure we can cover our costs on the Apify platform, we have a minimum charge of $X per API call, even if the response contains no results. Thus, we returned N pieces of mock data. We will monitor and adjust the size of N based on the infrastructure costs incurred by Apify. The publisher states the policy in the row itself; the store listing says $0.00025 per tweet and the input schema says nothing about a minimum. On a one-tweet lookup the effective price was $0.0033, fifteen times the per-tweet price, and any pipeline that counts rows will count fifteen tweets.
• apidojo Unlimited charged $0.0504 for one tweet. Its pricing has three event types: $0.016 per search or profile query (“includes first ~40 results”), $0.0004 per row above that, and $0.05 per single-tweet URL. The search and profile jobs cost the same as V2 because the query fee replaced the first 40 rows; the lookup did not. Both are in the run’s chargedEventCounts, and in the raw data below.
• xquik answered in 1.8 and 2.0 seconds. danek and scrape.badger took 3–6 s; apidojo V2 took 16 s for the image post and 4 s for the long-form one.
• Metrics agree. All six report 311 likes on the image post, and views within one count of each other.

7. Field coverage

Read from the 100 search rows of each actor, after mapping every actor’s names onto one list. “✓ when set” means the key is present only when it has a value (an empty media list is omitted rather than written as []). “—” means the actor never returns the field under any name.

• Tweet URL is missing from danek and scrape.badger. Both give you the id and the handle, so you build it yourself.
• Retweet flag is missing from xquik and danek in this output. For danek the nested retweeted_tweet object tells you anyway; for xquik nothing does, except the “RT @” prefix in the text.
• Long-form flag exists only in xquik (isNoteTweet).
• Source app is missing from kaitoeasyapi (the key exists, empty in every row).
• Naming. apidojo, kaitoeasyapi and xquik use camelCase; danek and scrape.badger use snake_case. danek returns three different record shapes for the three jobs (user_info on search, author on profile, likes instead of favorites on lookup) and returns views as a string. kaitoeasyapi’s record is apidojo’s record with four fields renamed, which makes the two nearly interchangeable.

8. Filters and the shape of the input

Read from each actor’s published input schema on 8 September 2026. We did not exercise every filter; this is what the schema offers.

• apidojo / Tweet Scraper V2. Clean field names; a custom JavaScript map function for reshaping output.
• kaitoeasyapi / Tweet Scraper (“cheapest”). Every X search operator is its own field, named after the operator (filter:blue_verified, -min_faves). No profile mode: use from:.
• apidojo / Twitter Scraper Unlimited. The small sibling of Tweet Scraper V2: same output, a fraction of the filters.
• xquik / X Tweet Scraper. Roughly a third of the 100 fields are aliases: the item cap alone can be spelled maxItems, maxResults, max_results, resultsLimit, resultsCount, numberOfTweets, maxPosts or max_posts. Output shape is configurable (legacy / rich / raw; camelCase / snake_case; nested / flat).
• danek / Twitter Scraper. Seven flat fields. Which ones apply depends on what you fill in; the schema does not say.
• scrape.badger / X Tweet Scraper. No profile mode: use from:. The mode string must match the label exactly.

9. Cost: what each Twitter scraper actually charged

• The listed price is not always the applied price. Apify lets publishers set different per-event prices for the FREE, BRONZE, SILVER and GOLD account tiers; the store shows one number. Our Starter-plan account was charged $0.00022 by kaitoeasyapi (listed $0.00025), $0.00028 by danek (listed $0.0003) and $0.00014 by scrape.badger (listed $0.00015). The other three charged the listed price.
• xquik is the only actor here where platform usage is billed to the user. On the search run that was $0.0013 of compute, storage and transfer on top of $0.015 in per-tweet events: about 8%. The store shows this as a small line under the price; the run object shows it as platformUsageBillingModel: USER. On a 256 MB run it is minor. On heavier settings it would not be.
• apidojo Unlimited’s per-query fee makes small pulls expensive and large pulls the same price as V2. Its single-tweet price is 125× the per-row price.
• kaitoeasyapi’s padding turns “no or few results” into a paid minimum, and the padding is billed as rows.

10. What we liked and what we did not

11. Best Twitter (X) scraper on Apify, by use case

There is no single winner, and we did not expect one. The six were chosen to be different, and they are. The one result we did not expect is that the oldest and most-used actor in the category, with 98,000 lifetime users, is the one that loses most of a long-form post, on a direct lookup as well as in search.

Disclosure

apifystats publishes no X actor and has no commercial relationship with any of the six publishers. None of them was contacted before or during the test. We paid list price from our own Apify account; the actors were not told they were being compared. This is the first post in a series; the method will change as we learn, and we will say so when it does.

12. Raw data

Everything the actors returned, untouched, plus the run objects Apify keeps for each run (timing, memory, charged events, applied pricing) and the exact input we sent. One directory per actor. If you find a mistake in our reading of it, tell us and we will correct the page.

• manifest.jsonl — one line per run: actor, job, run id, wall time, status.
• data.json — every number on this page, as produced by the analysis script.
• plan.json, run_tests.py, mapping.py, analyze.py, build_post.py — the plan with every input, the harness that ran the actors, the field mapping, the analysis, and the script that rendered this page (plus the census and DataForSEO helpers in the same folder).
• census candidates, six-week growth, store-search ranks, title and price events — the census extracts behind section 1, with the SQL.

Method notes and limits

• One run per job per actor, at one moment, with one query and one handle. A second day could move the timings; we do not expect it to move the text, price or schema findings, but we have not shown that yet.
• Timings include cold start and are measured by the platform, not by us. Memory was each actor’s default (128–512 MB).
• Prices applied to our account reflect its plan tier. Yours may differ; the run object will tell you.
• We did not test proxies, rate limits, very large pulls, or any filter beyond sort and cap.
• Success rates and user counts in section 1 are the store’s public statistics as captured by our daily census; we did not audit them. Definitions are on the methodology page.

13. Questions people ask about scraping Twitter (X)

Short answers from this test, for the questions that come up most in search.