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. The six were chosen on 8 September from that day’s census and were not re-chosen for the re-run; the table below is the census as it stood then.

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 24 runs were started inside the same second (12:56:49 UTC, 19 September 2026) from one Apify account on the Starter plan, through the API, with each actor’s default memory. On the first run (8 September) the twelve search and profile runs started at 22:13:48 UTC and the lookups 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 for five of the six, different text and different bills

Five actors returned the same 100 tweets. apidojo V2, apidojo Unlimited, kaitoeasyapi, danek and scrape.badger agree on every id, and the newest tweet is the same across all six (12:53:34 UTC, three minutes before the runs). Whatever these five do behind the scenes, they read the same source at the same moment. xquik did not: it shares 83 ids with the other five, returned 17 that none of them did, and left out 17 that all of them had. The union of the six result sets is 117 ids and 83 appear in all six. Of the 17 only xquik returned, 4 contain the phrase “web scraping”; of the 17 it left out, 9 do. On the first run, eleven days earlier, xquik agreed with the rest (99 of 101 ids in all six) and its search took 34 seconds; this time it took 5, and it did not read the same result set as the other five. View counts are identical for 98 of 100 shared tweets.

Where the five differ is the text. X allows posts far beyond 280 characters (long-form, or “note” tweets). 28 of the 100 tweets the five agreeing actors returned are long-form. kaitoeasyapi, danek and scrape.badger return 27 of them whole, xquik 34 of the 35 it saw. apidojo’s two actors return the first ~280 characters and stop, on 26 of the 28.

“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 ids xquik flags as isNoteTweet; the other actors do not flag them, but four of them return the same 1,000–6,000-character bodies. The one long-form post that no actor but apidojo returns “in full” is a 283-character post that apidojo returns with an expanded link, at 307 characters; the others’ 283 fall under the 95% rule, not under a cut. xquik sees 35 because 7 of its 17 extra tweets are long-form.

Speed ran from 5 s (xquik) to 40 s (apidojo Unlimited) for 100 tweets. Price per 1,000 ran from $0.14 (scrape.badger) to $0.40 (both apidojo actors). Records ran from 2.0 KB (danek) to 7.7 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” still means different things

This is the job where the six stop agreeing. The union of the six outputs is 81 distinct posts; 31 of them appear in all six, and 8 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, 11 retweets and 14 replies, with the pinned post first and flagged by both. The rows are not in date order: the pinned post, then a block that descends from 18 September to 15 September, then a jump back to 19 September and a second descent, and so on, which looks like several fetches concatenated. Sort before you use it. The retweet rows carry a cut text (“RT @…”, 10 of 11 end in “…”) with the original post attached as an object.
• xquik in profileTweets mode now returns the timeline too: 47 of its 50 are in apidojo V2’s 50, with 10 retweets and 16 replies, every one flagged (isRetweet, isReply), the retweeted text in full in the row and the original attached as retweetedTweet, in strict date order, in 6 seconds. (The same input returned no replies on the first run; section 13.)
• danek returns nearly the same set as apidojo (49 of 50 in common), attaches the original post to every retweet, and finished in 9 seconds. It returned 55 rows for a cap of 50, one of them twice, and billed 55.
• 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 29 and 28 replies out of 60 and 50 rows, reaches back only to 5 and 9 September, and has 32 and 31 posts in common with apidojo V2. kaitoeasyapi again 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; xquik gives it to you sorted and labelled, apidojo V2 and danek need a sort. If you need only original posts, no mode we ran does that now: filter on the reply and retweet flags. 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.
• Timings on a single lookup spread from 3 to 52 seconds. apidojo V2 answered the image post in 3 s and the long-form post in 52; xquik took 4 and 3; danek 4 and 6; scrape.badger 6 and 6; kaitoeasyapi 16 and 16; apidojo Unlimited 51 and 30. On the first run xquik answered both in 2 s and apidojo V2 took 16 and 4. One run per job, so treat a single lookup time as a sample, not a rate.
• Metrics agree. All six report 312 likes and 53,562 views on the image post.

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 danek in this output; the nested retweeted_tweet object tells you anyway. xquik carries an explicit isRetweet.
• 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 and read again on 19 September: the field counts and the required fields did not change (the schemas as read on 19 September are in the raw data). 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.0008 of compute, storage and transfer on top of $0.015 in per-tweet events: about 5% (9% on the first run, when the same job took 34 seconds instead of 5). 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 on the first run still stands on the second: 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. Before the first run, none of them was contacted and none was told they were being compared. Since 9 September the plan, the inputs and the scripts have been public on this page, so any publisher can read them and change their actor with the test in mind; a re-run measures whatever is live on the day, and this one did. We paid list price from our own Apify account both times. 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.
• Input schemas as read on 2026-09-19: apidojo / Tweet Scraper V2, kaitoeasyapi / Tweet Scraper (“cheapest”), apidojo / Twitter Scraper Unlimited, xquik / X Tweet Scraper, danek / Twitter Scraper, scrape.badger / X Tweet Scraper.
• archive/2026-09-08/ — the first run in full: the page as first published, its data.json, and every raw file. The text and the data are untouched; the archived page carries a banner, a noindex tag and repointed asset links so it renders from its folder.

Method notes and limits

• One run per job per actor, at one moment, with one query and one handle, on each of two dates eleven days apart. Between the dates the timings moved on every actor, the text, price and schema findings held for five of the six, and one actor changed its search result set and the meaning of its profile mode (section 13). A timing on this page is one sample.
• 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. What changed between 8 and 19 September

Same six actors, same plan, same inputs, same scripts, same account, eleven days apart. The first run is kept in full under archive/2026-09-08/. The table is computed from the two data.json files; the list below it is our reading.

Left of each arrow: 8 September. Right: 19 September. Build is the actor build number the platform recorded on the search run.

• xquik’s build number advanced by 73 (1.12.144 → 1.12.217), and two things we measure changed. Its search went from the slowest of the six (34 s) to the fastest (5 s), and stopped returning the same 100 tweets as the other five: 83 shared, 17 only it returned, 17 it left out (section 4). Its profileTweets mode went from “original posts and retweets, no replies, retweets as unflagged stubs” to the timeline as X shows it: 47 of 50 in common with apidojo V2, retweets and replies flagged, the retweeted text in full, the original attached, in date order (section 5). “Retweets are not flagged and the original post is not included” was one of our four “did not like” items for xquik on 8 September; it is gone, and so is “slowest on the search job”. Platform usage billed to the user fell from 9% to 5% of the search bill because the run is shorter.
• apidojo’s build numbers advanced by 11 on each actor. Search got slower (25 → 37 s and 24 → 40 s). Twitter Scraper Unlimited returned and flagged the pinned post this time, which it had dropped on 8 September. The long-form cut did not move: 2 of 28 whole in search, 277 of 1,334 characters on the direct lookup, on both dates.
• kaitoeasyapi (build number +3): the same 14 mock_tweet filler rows on a one-tweet lookup, 60 rows for a cap of 50, billed 60. Unchanged.
• danek (no new build): 55 rows for a cap of 50 where it had returned 50 with two duplicates; billed 55. Otherwise the same.
• scrape.badger (no new build): the same results, 3 seconds slower on search (15 → 18 s) and no longer the fastest.
• Retrieval agreement. Search: 99 of 101 ids in all six on 8 September; 83 of 117 on 19 September, all of the difference from xquik. Profile: 14 of 101 in all six, then 31 of 81; the six agree more because xquik’s mode now returns the timeline.
• What did not change: the cheapest and most expensive per 1,000 (scrape.badger $0.14, apidojo $0.40), the applied-versus-listed prices, apidojo Unlimited’s $0.05 single-tweet fee, the field coverage table except xquik’s new retweet flag, and the input schemas.
• Method. One change to our scripts: mapping.py now reads xquik’s isRetweet flag, which did not exist on 8 September. Everything else ran unchanged; the copy under raw/tools/ is what ran.

14. Questions people ask about scraping Twitter (X)

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