X (Twitter) Scraper

Read X three ways: by handle, by post ID, or by search term. You get the full profile with follower counts, plus posts carrying likes, reposts, replies, quotes, bookmarks and view counts.

No login, no cookies, no API key.

What you get

Per account, in the run summary: follower count, following count, total posts, bio, location, join date, verification, profile and banner images.

Per post, one row each:

• text, untruncated, and created_at
• like_count, retweet_count, reply_count, quote_count, bookmark_count and view_count
• is_retweet and is_quote, so reposts can be separated from original posts in one filter
• conversation_id, which lets replies be grouped back into threads
• hashtags, mentions, links and media_urls
• lang, username, user_id, user_followers and a direct url

View counts are the one most people are surprised to get: X publishes them on posts but not on every surface, and they come through here.

Advanced-search operators

X's own search syntax works as input, the one documented at igorbrigadir/twitter-advanced-search. Paste a query you already use and it is parsed rather than treated as literal words.

Honoured, and how:

operator	how it is served
from:	routed — that account's timeline is read directly, which is better data than finding the same posts by search
lang: since: until: since_time: until_time:	applied to the results
min_faves: min_retweets: min_replies:	applied to the results
conversation_id: url:	applied to the results
filter: / -filter: / exclude:	images, videos, media, quote, links, replies, nativeretweets

Not honoured, and reported rather than dropped: the geo family (geocode: near: within: place:) because no row carries coordinates; the card family and source: because those fields are not published on the surfaces read here; list: because list timelines need a signed-in session; and to: quoted_tweet_id: quoted_user_id: max_id: since_id:.

If you pass one of those, the run summary lists it under operatorsIgnored with a note saying the results are wider than your query asked for. That is the whole point of reporting it: an operator that vanishes quietly gives you rows you believe were filtered.

The same filters are also available as ordinary form fields (author, language, minimum likes, date range, only-images and so on) if you would rather not write the syntax. Both spellings are the same vocabulary and can be mixed; a operator written in a term beats a form field of the same name.

How search works here, and what that costs you

X refuses its own search to anyone who is not signed in. Twelve published query ids for its search endpoint all return "not found", and every older REST search path is gone. So search cannot be done on X directly.

What this Actor does instead is a two-step: Yahoo supplies the URLs of posts matching your phrase, and then each post is read from X itself.

Both halves are free. Yahoo is read directly, so there is no API key to obtain and no metered service in the middle: a run costs its own requests and nothing else.

That distinction is the important one:

• The data is first-hand. Likes, reposts, views and text all come from X at the moment of the run, not from a cached search snippet.
• The discovery is second-hand. You get posts a search engine has indexed, which skews toward posts that have been public for a while. Something posted in the last hour will usually not appear.

Every row records which it was in a discovery field: x-timeline, tweet-id or search-engine. Nothing is implied, so a mixed run stays honest.

The run summary reports tweetsDiscoveredBySearch alongside searchHydrationRate, the share of discovered posts that still resolved. A search index outlives deleted posts, so that number is rarely 100%, and seeing it is better than quietly getting fewer rows than you asked for. A typical run lands between 60% and 100%.

Fetching single posts

A target made only of digits is treated as a post ID rather than a handle, which is unambiguous because X handles cannot be all digits. That path uses a different door and needs no session at all, so it is well suited to bulk hydration: give it a list of IDs you already have and it fills in the text and engagement for each.

Fewer fields come back that way (reposts, quotes, bookmarks and views are not published on that surface), which the empty columns will show you honestly.

Protected accounts

A protected account returns its profile and no posts. That is the account's own setting, not a failure, so it is reported as such: the profile appears in the summary and the handle is listed under protected accounts rather than under errors.

Input

• Handles or post IDs — nasa, @openai, or a numeric ID
• Search terms — web scraping, nasa artemis. Mix these with handles in the same run; they are separate fields so an ambiguous word like apify is never guessed at.
• Maximum posts per search term and search pages per term
• Maximum posts per account — pages are walked until this is reached. Set it to 0 for profiles only, which turns each account into a single request: three accounts came back in about five seconds that way, against ten for the same three at forty posts each.
• Maximum targets, targets in parallel and retries
• Request from country, optionally

Keep parallelism modest. Each account is a profile lookup followed by several sequential page requests, so concurrency multiplies quickly.

Run summary

Targets requested, profiles found, posts returned, protected accounts, total likes and total views across everything collected, and how many posts were reposts rather than original.

What people use this for

Competitor and brand monitoring. Follower counts alongside per-post engagement, collected on a schedule, show both audience growth and what actually lands.

Engagement benchmarking. Because view counts come through, engagement can be measured as a rate rather than as a raw like count, which is the only version of that number that compares across accounts of different sizes.

Thread reconstruction. conversation_id groups a thread back together from the posts you collected.

Bulk post hydration. If you already have post IDs from somewhere else, feeding them in fills in text and engagement for each.

Scale and cost

A profile lookup is one request. Each page of posts is another and returns about 20, so an account at 40 posts costs three requests in total. Two accounts at 40 posts each returned 81 rows in 46 seconds in testing, including one target that did not exist and was reported as an error.

Profiles-only runs are much cheaper: setting posts per account to 0 makes each target a single request, which is the right setting when you are tracking follower counts across a long list.

Nothing needs configuring and nothing needs to be kept alive between runs: there is no key to obtain, no account to connect and no credential to rotate.

A note on what this reads

Everything here is what a signed-out visitor can see: public accounts, public posts, public counts. Protected accounts return a profile and no posts, exactly as they would to any visitor, and no attempt is made to see past that.

What this is not

There are actors on the Store that reach 30 to 80 posts per second and offer Top/Latest sorting. They get that by driving X's own search with signed-in sessions. This one reads what a signed-out visitor can see, so it is slower and has no sort control, and it will not pretend otherwise.

Where it is competitive: reading named accounts, where the timeline door gives full first-hand data, and applying the filters above to whatever it collects.

Notes

Engagement moves quickly on fresh posts, so two runs minutes apart will legitimately disagree. That difference is the data rather than an error.

Reposts appear as rows with is_retweet true and, typically, zero likes of their own: the engagement sits on the original post, not on the repost. Filter on that flag rather than treating those as underperforming posts.

Deleted posts and suspended accounts return nothing and are reported as errors naming the target rather than dropped silently from the output.

If X ever changes the endpoint this reads, every target fails at once. That case is reported as its own error rather than as "none of your accounts exist", and the run summary flags it, so a failed run tells you whether the problem is your input or ours.

Rows are deduplicated on the post ID within a run.