Scweet — Twitter/X Scraper

Extract tweets and follower lists from X/Twitter into JSON, CSV, XLSX and 4 more formats. No API key, no cookies, no account setup — just configure your job and Scweet handles the rest.

Run on Apify | Open-Source Library

---

What Scweet Does

• Four things to scrape — tweets from a search, tweets from a profile timeline, the details of a profile, or the followers and following lists of a profile. Each run does one of them and returns one kind of row.
• Search that goes deep — query by keywords, hashtags, users, engagement, date range, location, and more.
• Zero configuration — no cookies, no proxies, nothing to manage. Just set your query and Scweet handles the rest.
• Deduplicated billing — you only pay for unique rows. Every item is deduplicated before it reaches your dataset, whether it is a tweet or a profile.
• Production-grade reliability — automatic retries, adaptive rate limiting, and built-in resilience keep runs stable at scale.

Use cases

Brand monitoring, lead generation, market research, academic datasets, OSINT, content strategy.

Pricing

Plan	Per 1,000 rows	Run-start fee, for each GB of memory
Free	$0.30	$0.006
Starter	$0.30	$0.006
Scale	$0.28	$0.006
Business	$0.25	$0.006

You pay only for unique, deduplicated rows. A tweet and a profile cost the same. A run uses 1 GB of memory by default and can use up to 2 GB; the run-start fee applies once for each GB, so a run at 2 GB pays $0.012.

Free trial: 3,000 tweets, up to 1,000 in a run, one run at a time. Every free run tells you how many tweets remain.

---

Quick Start

1. Open Scweet on Apify.
2. Paste one of the inputs below.
3. Run the Actor.
4. Export your dataset (JSON, JSONL, CSV, XLSX, HTML, XML or RSS).

Search

{
  "source_mode": "search",
  "search_query": "bitcoin lang:en from:elonmusk -filter:replies min_faves:100",
  "since": "2025-02-17",
  "until": "2026-02-19",
  "max_items": 1000
}

Profile timeline

{
  "source_mode": "profiles",
  "profile_urls": [
    "https://x.com/elonmusk",
    "@apify"
  ],
  "max_items": 1000
}

Followers or following

One row for each profile in the list. Set relationship to choose the list.

{
  "source_mode": "followers",
  "profile_urls": ["@apify", "@elonmusk"],
  "relationship": "followers",
  "per_profile_limit": 500,
  "max_items": 1000
}

The run above returns up to 500 rows for each of the two profiles. Without per_profile_limit, the first profile can use the whole 1,000.

Input can be partial — omitted fields use defaults. The Apify Console opens with sample prefill values. Replace or remove them before running your own job.

A run reads one source. If you send both a query and profile_urls with source_mode: auto, the run reads the search and tells you so in the log.

---

Input Reference

Source modes

Pick one. A run reads one source and returns one kind of row, so your dataset never mixes shapes.

Mode	What you get	What you provide
search	tweets that match your query	search_query or the builder fields
profiles	tweets from each profile timeline	profile_urls
followers	one row for each profile in the list, with its details	profile_urls
auto (default)	reads the search when a query is present, otherwise the profiles	either

relationship applies to the followers mode: followers (default), following, or verified_followers.

Core fields

Field	Type	Description
source_mode	string	search, profiles, followers, or auto (default: auto)
relationship	string	For followers mode: followers, following, or verified_followers (default: followers)
search_query	string	Raw advanced query string. Operator reference
profile_urls	array	Handles or profile URLs (@handle, x.com/<handle>, twitter.com/<handle>)
max_items	integer	Total rows for the whole run (default: 1000)
per_profile_limit	integer	Optional. Largest number of rows for each profile. Without it, one profile can use the whole run.
since	string	Start date or UTC timestamp
until	string	End date or UTC timestamp
search_sort	string	Top or Latest (default: Top)

Search builder fields

Instead of writing a raw search_query, you can use structured fields that Scweet combines into a query automatically:

Category	Fields
Keywords	all_words, any_words, exact_phrases, exclude_words
Users	from_users, to_users, mentioning_users
Hashtags	hashtags_any, hashtags_exclude
Language	lang (e.g. en, fr, ar)
Tweet type	tweet_type: all, originals_only, replies_only, retweets_only, exclude_replies, exclude_retweets
Filters	verified_only, blue_verified_only, has_images, has_videos, has_links, has_mentions, has_hashtags
Engagement	min_likes, min_replies, min_retweets
Location	place, geocode (lat,lon,radius), near, within

Defaults and limits

• max_items is the total for the whole run. Set per_profile_limit to give each profile its own share; without it, one profile can use the whole run.
• Minimum run size: if max_items < 100, it is auto-adjusted to 100.
• Unknown input keys are rejected.
• If both since and until are missing, lookback defaults to 4 years (Top) or 180 days (Latest).
• Location filters depend on X/Twitter metadata and can be approximate.
• Free trial: 3,000 tweets in total, up to 1,000 in a run, one run at a time. The last run receives what remains, and every free run states how many remain.
• The same trial applies to every mode: tweets, profile timelines and follower lists count toward the one total.

---

Output

Results are stored in the Apify dataset and deduplicated, so you never pay for the same row twice. Export as JSON, JSONL, CSV, XLSX, HTML, XML or RSS, with no row limit.

The shape of a row follows the mode. The Output tab of a run offers a view for each shape: Tweets for the search and the profile timeline, Profiles for the follower lists. A run fills one view, and the other one stays empty. The Tweets view opens first, so a run of the followers mode names its own view at the end of the log.

How a run ended

A program that calls the actor does not read the log. So every run also writes how it ended in two places a program reads:

• The status message of the run. One sentence, on the run object of the API (statusMessage) and at the top of the run in the Console. For a free run it holds the state of the trial: "Free trial: 1,200 of 3,000 used, 1,800 remain."
• The record OUTPUT in the key-value store of the run. The tab Output links to it as How the run ended, and the API serves it at /v2/key-value-stores/<storeId>/records/OUTPUT.

{
  "outcome": "delivered",
  "message": "Done! 1,000/1,000 tweets collected. Free trial: 1,200 of 3,000 used, 1,800 remain.",
  "delivered": 1000,
  "requested": 1000,
  "free_trial": {"used": 1200, "total": 3000, "remaining": 1800},
  "subscribe": "https://apify.com/pricing"
}

outcome is one of these words, so a program can branch on it:

outcome	Meaning
delivered	the run met its target
delivered_partial	the run ended with fewer rows than the target; message says why
no_results	nothing matched; message says what to change
trial_complete	the free trial is spent; subscribe to continue
one_run_at_a_time	a free plan runs one job at a time, and one was in progress
low_result_cooldown	a free plan repeated a query that returns almost nothing; wait
quota_spent	a paid plan met its daily limit
no_capacity	the service was at its capacity for a moment; retry in a few minutes
invalid_input	the input holds no source or a bad value
error	the run did not finish; retry

A run that stops before it delivers, for any of the reasons above, charges nothing.

Fields of a tweet

Field	Description
id	Tweet ID
text	Tweet text
handle	Author handle
tweet_url	Direct link to tweet
favorite_count, retweet_count, reply_count, quote_count, bookmark_count, view_count	Engagement metrics
created_at	Tweet creation time
collected_at_utc	Collection timestamp (UTC)
lang	Language
conversation_id	Thread/conversation ID
in_reply_to_status_id, in_reply_to_user_id, in_reply_to_screen_name	Reply references
quoted_status_id	Quoted tweet ID
is_quote, is_reply	Convenience flags
source_root	search or profile_url
source_value	Effective query or normalized profile URL
requested_search	The same value as source_value. The Tweets view reads this name
user	Nested author object (handle, name, followers, bio, etc.)
tweet	Nested tweet details (media, entities, edit history, etc.)

Fields of a profile or a user

The followers mode returns this shape instead. Each row is one profile, so a follower list also gives you the details of every profile in it.

Field	Description
user_id	Numeric ID of the profile
handle	Handle, without the @
name	Display name
description	Bio
followers_count, following_count	Counts of the graph
tweets_count, media_tweets_count	Posts, and posts that carry media
favourites_count	Likes the profile gave
created_at	Date the profile joined X
joined_at	The same value as created_at. The Profiles view reads this name
location, website	As the profile states them
verified, blue_verified, identity_verified	Marks of verification
protected, possibly_sensitive	Flags of the profile
professional_type	For example Creator, when X sets it
profile_image_url, profile_banner_url	Images
profile_url	Link to the profile
source_root	followers, following, or verified_followers
source_value	The profile you asked for
requested_profile	The same value as source_value. The Profiles view reads this name
collected_at_utc	When the run read the row

Example (top-level fields)

{
  "id": "1996300676012376299",
  "handle": "FTB_Team",
  "text": "We dug through the first month of StoneBlock 4...",
  "favorite_count": 71,
  "retweet_count": 5,
  "reply_count": 10,
  "view_count": "9695",
  "tweet_url": "https://x.com/FTB_Team/status/1996300676012376299",
  "created_at": "Wed Dec 03 19:29:05 +0000 2025",
  "collected_at_utc": "2026-04-07T15:58:33.539740+00:00",
  "lang": "en",
  "source_root": "search",
  "source_value": "(sample OR query) lang:en",
  "requested_search": "(sample OR query) lang:en",
  "is_quote": false,
  "is_reply": false,
  "user": { "handle": "FTB_Team", "name": "Feed The Beast", "followers_count": 43367, "..." : "..." },
  "tweet": { "media": ["..."], "entities": { "..." : "..." }, "..." : "..." }
}

---

Tips

• Choose the sort by the breadth of your query, not the size of your job. search_sort: "Latest" reads tweets in order of time, so it collects the most for a query with recent activity, at every order size. Top reads a ranked selection, so it repeats tweets once you ask for more than the ranking holds. The trade is that Latest depends on the window: it returns nothing when the period holds no post, where Top almost always returns something. So use Latest by default, and switch to Top only when a narrow query returns nothing over a range you cannot widen.
• Use wider time ranges. The wider the since/until window, the more tweets X will surface. Scweet automatically splits wide ranges into parallel sub-intervals, so a large window does not slow down the run.
• Start broad, then narrow. If you get fewer tweets than expected, try removing restrictive filters (min_likes, tweet_type, lang) one at a time to see which one is limiting results.
• For large volumes from a single profile, use search instead of profile mode. Profile mode (source_mode=profiles) is best for recent activity. For thousands of tweets from a specific user, use source_mode=search with from_users: ["handle"] (or search_query: "from:handle"), a wide since/until range, and search_sort: "Latest" for more complete results.
• Date filters are handled internally. Scweet converts since and until to precise Unix-timestamp operators under the hood. You can keep using human-readable dates (e.g. "since": "2025-01-01").
• Give each profile its own share. With several profiles in one run, set per_profile_limit. Without it, the first profile can consume the whole max_items and the others return nothing.
• Follower lists are slower than tweets. X allows fewer requests for a social graph than for a timeline, so a large follower job takes longer than a search of the same size. Ask for what you need.
• Combine structured fields with search_query. You can use search_query for advanced operators not covered by the builder fields (e.g. filter:media, -filter:replies) and add structured fields like from_users or min_likes on top — Scweet merges them into a single query.

---

How It Works

Scweet uses X's internal GraphQL API — the same endpoints the X website uses. No official Twitter API key or developer account is needed.

You choose a source and a target. Scweet handles everything else — authentication, proxies, pacing, retries, and deduplication. If something fails mid-run, work is automatically retried so you get complete results without manual intervention.

Each source has its own pacing, because X allows a different number of requests for a search, for a timeline, and for a social graph. Scweet respects each one, so a large job stays stable instead of stopping halfway.

---

FAQ

Do I need a Twitter API key? No. Scweet uses X's internal GraphQL API — no developer account or API key required.

Do I need to provide cookies, a login or proxies? No. You provide nothing but your query. Everything else is handled for you.

Can I scrape protected profiles? No. Only publicly visible content is accessible.

What export formats are supported? Seven: JSON, JSONL, CSV, XLSX, HTML, XML and RSS. Download any of them from the dataset tab of a run, or fetch one from the API by adding format=:

https://api.apify.com/v2/datasets/<datasetId>/items?format=csv&token=<yourToken>

An export holds every row, whatever its size. Use JSONL to read a large result line by line instead of loading it whole.

Is there a free tier? Yes. A free plan receives a trial of 3,000 tweets, up to 1,000 in a run, one run at a time, at the same $0.30 for each 1,000 as a paid plan. The same trial covers tweets, profile timelines and follower lists. After the trial, subscribe to any Apify plan to continue.

Can I get the followers of a profile? Yes. Set source_mode to followers and choose relationship: followers, following, or verified_followers. Each row is one profile.

Can I get the follower count and the bio of a profile? Yes. Every row of the followers mode carries them: the counts of followers and posts, the bio, the location, the joined date, and the marks of verification.

Is there an open-source version? Yes. Scweet is our MIT library, and this Actor is the hosted service built on it. The library needs you to supply your own X accounts, refresh their cookies, manage proxies, and follow every change X makes to its API. This Actor does that work for you. Use the library if you want to run the infrastructure yourself. Use this Actor if you want the data.

---

Support

For help with query tuning, limits, or workflow design, contact us on the Actor page or open an issue in the open-source repository.

Responsible usage: Use this Actor lawfully and ethically. Comply with applicable platform terms and local regulations. Scweet applies adaptive rate limiting — repeatedly running queries that return zero results will trigger progressively longer cooldowns.

Privacy: Run metadata (user ID, timestamps, input payload, counters) may be stored for rate limiting, support, and stability. This data is used internally and is not shared with third parties.