Twitter (X) Search Scraper — tweets by keyword

Put in a search query, get back the tweets. Full text, likes, retweets, replies, quotes, bookmarks, views, media, and the author with their bio and follower counts attached. X's advanced operators all work — from:, to:, min_faves:, filter:media, -filter:replies, lang:, quoted phrases.

You don't need to log in, register a developer account, or go and find a cookie. Which needs explaining, because search is the one thing on X that genuinely can't be done signed out.

Where the session comes from

X does not serve search to a guest token. The identical request that returns a full profile with no credentials returns an empty payload for a search. Rotating addresses doesn't help. Nor does a cleaner browser fingerprint. The endpoint is closed to callers who aren't signed in.

So the actor carries its own logged-in session and uses it on your behalf. No login is needed from you, but it isn't accurate to call this a keyless scrape, and it would be dishonest to imply nothing is signed in. Something is: an account we run.

That session is shared with everyone else using this actor, and X counts rate limits per account rather than per caller. Under heavy concurrent load it throttles, and your run can come back short or with a BLOCKED diagnostic row saying why. That's the trade for not having to set anything up.

If you're pulling at volume, or you just don't want your throughput tied to how busy the actor is, put your own cookie in sessionCookies and the run uses only yours — a rate limit nobody else draws on. Your cookies are never mixed with the built-in one.

Getting your own cookie takes about a minute:

1. Log in to x.com (a throwaway account is fine, and a sensible choice).
2. F12 → Application → Cookies → https://x.com.
3. Copy the values of auth_token and ct0.
4. Paste as auth_token=XXXX; ct0=YYYY into sessionCookies. One account per line — several lines are rotated, and one going quiet doesn't stop the run.

What each row looks like

{
  "ok": true,
  "charged": true,
  "id": "2090836814202388875",
  "url": "https://x.com/handle/status/2090836814202388875",
  "text": "the full tweet text, not truncated",
  "createdAt": "Fri Aug 21 16:21:57 +0000 2026",
  "lang": "en",
  "replyCount": 0,
  "retweetCount": 0,
  "likeCount": 0,
  "quoteCount": 0,
  "bookmarkCount": 0,
  "viewCount": null,
  "isReply": true,
  "isRetweet": false,
  "isQuote": true,
  "conversationId": "2090836139414364439",
  "inReplyToId": "2090836539211214939",
  "inReplyToUser": "handle",
  "hashtags": [],
  "mentions": [],
  "urls": ["https://x.com/OpenAI/status/2090165329867743501"],
  "media": [],
  "author": {
    "id": "82559544",
    "userName": "handle",
    "name": "Display Name",
    "description": "the account bio",
    "followersCount": 1591,
    "friendsCount": 489,
    "statusesCount": 2910,
    "verified": true,
    "isBlueVerified": true
  }
}

The author object is filled in on this route, so you get follower counts without a second lookup. viewCount is null on tweets where X doesn't publish it — usually very new or very small ones.

Input

{
  "searchTerms": ["\"open source\" min_faves:50 -filter:replies"],
  "sort": "Latest",
  "maxItems": 100,
  "since": "2026-08-01"
}

Field	Default	Notes
searchTerms	—	One or more X search queries. Advanced operators behave exactly as they do on x.com.
sort	Latest	Latest for newest first, Top for X's relevance ranking.
maxItems	100	1 to 5,000 per run. This is your spend cap.
since / until	—	YYYY-MM-DD bounds, folded into the query.
onlyVerifiedUsers	false	Keep only verified authors. Filtered-out tweets aren't charged.
sessionCookies	—	Optional. auth_token=…; ct0=…, one account per line. Stored as a secret.
proxyConfiguration	Apify datacenter	Leave it. Traffic goes out over rented static addresses with rotating Apify datacenter behind them; neither is billed by the gigabyte. Metered groups like RESIDENTIAL aren't offered and are swapped for datacenter if you ask. Your own servers in proxyUrls are used exactly as given.
notionConnector / notionParentId	—	Optional: write each tweet into a Notion database too.

Limits

• Search walks up to 100 pages per term. A wide query with a distant since date can exhaust that budget before it reaches your window; the run logs how far back it got.
• Tweets are deduplicated by id across all your search terms, so the same tweet is never returned or charged twice in one run.
• If every session in the pool is exhausted, the run still succeeds. It returns a single clearly labelled _sample row so you can see the output shape, and no per-tweet fee is charged for it. A dead cookie is dropped for the rest of the run and the next one is tried.
• A transient upstream failure is retried, not reported as "no results". X occasionally answers a perfectly valid search with a 404 or a 5xx. Those are retried, from a different exit address, before a term is given up on. If every attempt on every term still fails, the run fails with the reason instead of finishing as a success with no rows -- nothing is charged either way, so a failed run costs you nothing and can simply be re-run.
• X's search index doesn't go back forever, and it isn't exhaustive. That's X's behaviour, not the actor's. Run the same query in a browser and you get the same set back.

Billing

$0.0004 per tweet returned ($0.40 per 1,000). Flat on every Apify plan, no volume tiers.

A run also costs $0.001 to start, charged once whatever the run then does.

Everything else is free: sample rows, diagnostic rows, tweets your filters removed, duplicates, and a search that comes back with nothing. A run that finds no tweets costs the $0.001 and no more.