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:39:08 UTC, 2026-09-20) from one Apify account on the Starter plan, through the API, with each actor’s default memory. Every earlier run followed the same rule (on the first run the twelve lookups started about ten minutes after the rest).
• 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 tweets. apidojo V2, apidojo Unlimited, kaitoeasyapi, danek and scrape.badger agree on 99 to 100 of their 100 ids, and the newest tweet is the same across all six (12:09:20 UTC, 30 minutes before the runs). Whatever these five do behind the scenes, they read the same source at the same moment. xquik reads it differently. Its 100 holds 83 of the five’s posts, every one of theirs that falls inside its time window (83 of 83), and 17 posts the five do not return: 9 long-form posts in which the query words first appear after character 280, 5 posts that carry an X Article, and 3 short replies whose own text has neither word. Those 17 take the place of the 17 oldest posts in the five’s 100 (17 of the 17 are older than xquik’s oldest row). In this set, “search” means two things: a match on the first 280 characters of a post, or a match on its full text and its Article body. Which one you want depends on the job. View counts are identical for 97 of 100 shared tweets.

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

“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. xquik sees more long-form ids because some of the posts only it returns are long-form.

Speed ran from 10 s (xquik) to 43 s (apidojo V2) for 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 7.8 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 10 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, 10 retweets and 15 replies, both flagged. The rows are not in date order (63% of consecutive pairs descend): blocks of a few days each, concatenated, which looks like several fetches joined. Sort before you use it. The retweet rows carry a cut text (“RT @…”, 9 of 10 end in “…”) with the original post attached as an object.
• xquik in profileTweets mode returns the timeline too: 49 of its 50 are in apidojo V2’s 50, with 9 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 9 seconds.
• danek returns nearly the same set as apidojo (50 of 50 in common), attaches the original post to every retweet, and finished in 7 seconds. It returned 55 rows for a cap of 50 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 28 and 28 replies out of 60 and 50 rows, reaches back only to 5 and 11 September, and has 32 and 32 posts in common with apidojo V2. kaitoeasyapi 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: 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 4 to 31 seconds: apidojo / Tweet Scraper V2 28 s and 8 s; kaitoeasyapi / Tweet Scraper (“cheapest”) 14 s and 15 s; apidojo / Twitter Scraper Unlimited 31 s and 20 s; xquik / X Tweet Scraper 6 s and 6 s; danek / Twitter Scraper 5 s and 4 s; scrape.badger / X Tweet Scraper 17 s and 6 s. One run per job, so treat a single lookup time as a sample, not a rate; they move from run to run (section 13).
• Metrics agree. All six report 312 likes on the image post, and views within a few counts 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 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 2026-09-20 (the files are in the raw data). Five schemas are unchanged since 8 September; xquik’s went from 100 fields to 82, the alias spellings of the item cap and the target lists gone. 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. One field per operator plus the mode switches; the item cap is maxItems. 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.0009 of compute, storage and transfer on top of $0.015 in per-tweet events: about 6% (5% on the previous run; it moves with the run’s duration). 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 has held on every run since: 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 every time. 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-20: 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/, archive/2026-09-19/ — every earlier run in full: the page as it was published that day, its data.json, and every raw file. The text and the data are untouched; each 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 run date. Between runs the timings move on every actor; the text, price and schema findings have held (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. Run history

Same six actors, same plan, same inputs, same scripts, same account, on 2026-09-08 → 2026-09-19 → 2026-09-20. Every earlier run is kept in full under archive/. The table is computed from the data.json of each run; the list below it is our reading.

Columns read 2026-09-08 → 2026-09-19 → 2026-09-20. Build is the actor build number the platform recorded on the search run.

• Retrieval agreement. Search, ids in all six of the union: 99 of 101 → 83 of 117 → 83 of 119. Profile: 14 of 101 → 31 of 81 → 31 of 81. Since 19 September the search difference is xquik’s alone and has one shape: its 100 is the five’s newest posts plus full-text and Article matches in place of their oldest (section 4).
• xquik — search time 34 s → 5 s → 10 s. On 8 September its search returned the same set as the five; since 19 September it matches full text and Article bodies too. Its profileTweets output returned no replies on 8 September and the labelled timeline since.
• apidojo — the long-form cut has not moved on any run (277 of 1,334 characters on the direct lookup). Twitter Scraper Unlimited dropped the pinned post on 8 September and returned it on 19 September; on 20 September the account had no pinned post.
• kaitoeasyapi — the same 14 mock_tweet filler rows on a one-tweet lookup and 60 rows for a cap of 50 on every run.
• danek — 50 rows with two duplicates on 8 September, 55 rows since (one duplicate on 19 September, none on 20 September), billed per row.
• scrape.badger — no new build and the same results on every run; only the timings move.
• What has not changed: the cheapest and most expensive per 1,000 (scrape.badger $0.14, apidojo V2 $0.40), the applied-versus-listed prices, apidojo Unlimited’s $0.05 single-tweet fee, the field coverage table except xquik’s retweet flag (added 19 September), and the input schemas of five actors (xquik’s dropped 18 alias fields by 20 September).
• Method. One change to our scripts since the first run: mapping.py reads xquik’s isRetweet flag, which did not exist on 8 September. Everything else runs 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.