Best Twitter Scraper 2026: API, Browser and Python Compared

Every tweet you want is still public. What actually changed in 2026 is the price of reaching that data at any real volume, and the legal temperature around the methods people use to get it. The free X tier dropped read access entirely, Nitter went dark, snscrape mostly stopped returning rows, and X has started taking scrapers to court. So the question is no longer "can I scrape Twitter," it is "which path survives a production workload without breaking your budget or crossing a legal line."

Short answer: there are four live ways to collect Twitter data this year, the official X API ($0.005 per read), a managed third-party API such as TwitterAPIs ($0.0008 per call, around $0.04 per 1,000 tweets), self-hosted browser automation (Playwright or Puppeteer), and free Python libraries (Twikit, Twscrape). If the data feeds something real, a managed API is the cheapest, calmest, and most durable of the four. The self-hosted routes only pay off when you can swallow the proxy bill, the maintenance churn, and the terms-of-service exposure yourself.

Researchers, analysts, monitoring tools, trading desks, and bot builders all still need this data. This guide walks the four categories that genuinely work in 2026 and grades each on price, legality, how often it breaks, and how much work it is to stand up.

This page is the buyer's-eye comparison. For the TwitterAPIs scraper product itself and its pricing, see the Twitter scraper page. If you want a step-by-step beginner path, read how to scrape tweets without getting blocked; for scaling a scraper in production, see production Twitter scraping best practices.

Four routes to the same JSON

There are exactly four routes to Twitter data in 2026, and they sit far apart on every axis that matters. One bills per call and runs its own infrastructure, one is the sanctioned but expensive path, and two are free in the sticker sense while costing you maintenance time, proxy fees, and legal risk instead. Here is the shape of the field before we go deep on each.

Method	Per-call price	Breaks often?	ToS exposure	Effort to set up
Managed API (TwitterAPIs)	$0.0008 read, $0.0008 to $0.0016 write	Rarely	Low (for the caller)	Minimal
Official X API	$0.005 read, up to $0.015 write	Rarely	None	Moderate
Python libraries (Twikit, Twscrape)	Free	Often	Medium to high	Moderate
Headless browser (Playwright)	Free plus proxies	Constantly	High	Heavy

Pricing per the TwitterAPIs pricing page and the 2026 X API pricing change.

The rest of this guide takes them in order of how often we actually recommend them, starting with the managed API and ending with browser automation.

---

Route 1: A managed Twitter data API (TwitterAPIs)

A managed API hands you the same structured data the official endpoint returns, except the provider runs the proxy pool, the retry logic, and the anti-bot layer on its own servers. With TwitterAPIs that means $0.0008 per read call, roughly 6 times under the official Basic read price, and a setup that takes about five minutes: register, copy a key, send requests behind one Authorization header. There is no developer-account review, no OAuth dance, and no 2-million-tweet monthly ceiling.

What the request loop looks like

You sign up, grab a key, and start calling. No application form, no token exchange. Your client hits a TwitterAPIs endpoint, and structured Twitter JSON comes back.

// Pull the accounts a handle follows
const res = await fetch(
  "https://api.twitterapis.com/twitter/user/following?userName=nasa",
  { headers: { Authorization: `Bearer ${process.env.TWITTERAPIS_KEY}` } }
);
const following = await res.json();

Reads, writes, and what each costs

TwitterAPIs exposes 48 endpoints in total: 34 read endpoints (including single-tweet and full-thread fetches) and 14 write endpoints. Every read call is a flat $0.0008 and returns up to about 20 tweets, which works out to roughly $0.04 per 1,000 tweets. The 12 write actions, favorite and unfavorite, retweet and unretweet, bookmark and unbookmark, follow and unfollow, delete, tweet creation, media upload, and DM send, bill at $0.0008 per call for the simple actions, with tweet creation and DM send at $0.0016. Writes use bring-your-own credentials: you pass an auth_token and ct0 on each write request, and they are never stored server-side. Sending a direct message runs through the dm/send endpoint on that same model, so DMs sit alongside the engagement, relationship, and posting actions above, all covered here.

Action	TwitterAPIs	Official X API	Gap
Read a tweet	$0.0008	$0.005	~6x cheaper
Look up a user	$0.0008	$0.010	~12x cheaper
Favorite / retweet / follow / bookmark	$0.0008	$0.015	~19x cheaper

Pricing per the TwitterAPIs pricing page and the 2026 X API pricing change.

Run the math on 100,000 read calls in a month and it is an estimated $80 on TwitterAPIs against $500 on the official Basic tier.

Where it shines

• Reads land 6 to 12 times below the official price, simple writes around 19 times below
• No account approval gate, the key works the moment you register
• No monthly read cap to design around
• $0.50 in free credits at signup with no card, about 625 calls or 12,500 tweets
• One Bearer header, no OAuth state machine

The tradeoffs

• You depend on a third party operating the infrastructure layer
• Not a fit when compliance demands a direct, sanctioned channel into the platform

Who it suits

Almost every workload: analytics, monitoring, research, bots, and bulk collection. Skip it only if you specifically need OAuth user-context flows or a compliance mandate that forces first-party access.

See the full pricing →

---

Route 2: The official X API

The official X API is the one path with zero terms-of-service exposure. Every read is authorized, the official X API documentation is open, and the schema barely moves. The catch is the bill: $0.005 per tweet read on the Basic tier, which is $500 for 100,000 reads in a month, and a hard wall at 2 million reads before Enterprise opens at $42,000 per month. The tiers have been reshuffled more than once, and the 2026 X API pricing change tracks what shifted last.

Getting started

Head to console.x.com, spin up a project, generate keys, load credits, and start calling. Each request burns down your balance.

Per-operation pricing

Operation	Price per call
Read a post	$0.005
Look up a user profile	$0.010
Create a post	$0.010
Follow / like / retweet	$0.015

Official X API prices per the 2026 X API pricing change.

The free tier still exists, but it is write-only: no reads at all. Any collection workload pays from call one.

How that scales:

Monthly volume	Post reads	User lookups
10,000	$50	$100
100,000	$500	$1,000
1,000,000	$5,000	$10,000

Official X API prices per the 2026 X API pricing change.

And again, the ceiling is 2 million reads per month, after which Enterprise pricing ($42,000+/month) is the only door.

Throttling

Endpoint	Limit
Tweet lookup	300/15min (app), 900/15min (user)
Recent search	450/hour
User timeline	75/hour
Followers / following	Paginated, tier-dependent

These windows are usually the first thing a production pipeline runs into, and the Twitter API rate limit guide covers which endpoints choke hardest and how to budget your retries.

Where it shines

• Fully sanctioned, no terms-of-service risk whatsoever
• It is the source of truth, so reliability is high
• Clean structured JSON
• Real OAuth for user-authenticated actions
• A 24-hour dedup window trims cost on repeat lookups

The tradeoffs

• Costly once volume climbs
• The 2-million read ceiling
• Backoff logic is mandatory under the rate limits
• A developer-account review stands between you and a key
• No read access on the free tier

Who it suits

Compliance-bound projects, enterprise products, and anything where legal exposure is simply not on the table.

---

Route 3: Free Python libraries (Twikit, Twscrape, snscrape)

Python scraper libraries reach the data by calling X's internal GraphQL API directly, with no official key. They are free and hold up at low to moderate volume, but they breach X's terms, lean on real account credentials, and snap whenever X rotates its internal token logic.

State of play (March 2026)

Library	Status	Mechanism
Twikit	Maintained	X internal API, no official key
Twscrape	Maintained	X internal API with multi-account auth
snscrape	Flaky	HTML endpoints, breaks constantly
Tweepy	Maintained	Official wrapper, needs keys and credits
Nitter	Dead (Feb 2024)	Leaned on guest accounts X killed

A Twikit run

import asyncio
from twikit import Client

bot = Client()

async def run():
    await bot.login(
        auth_info_1="handle",
        auth_info_2="me@example.com",
        password="secret",
    )
    hits = await bot.search_tweet("open source", "Latest")
    for h in hits:
        print(h.user.name, "->", h.text)

asyncio.run(run())

A Twscrape run

import asyncio
from twscrape import API

pool = API()

async def run():
    await pool.pool.add_account("login", "pwd", "mailbox", "mailbox_pwd")
    await pool.pool.login_all()
    async for tw in pool.search("from:nasa", limit=25):
        print(tw.id, tw.rawContent[:60])

asyncio.run(run())

Where it shines

• Free, no per-call charge
• A plain Python surface
• Twikit and Twscrape both see active maintenance
• Fine for moderate-volume collection

The tradeoffs

• Built on undocumented internals, so it can die without warning
• Needs live X account credentials, which puts those accounts at suspension risk
• Same terms-of-service exposure as browser scraping
• No uptime or completeness guarantee
• Capped by X's internal throttling

Who it suits

Hobby builds, academic work, personal dashboards, anywhere occasional breakage and the terms risk are acceptable.

---

Route 4: Headless browser automation (Playwright / Puppeteer)

Browser scraping drives a real Chromium or Firefox session, signs into X with live credentials, and reads tweets out of the rendered DOM. In 2026 that means residential proxies ($50 to $200 a month), stealth patches to slip past headless detection, a session refresh every few hours, and upkeep every time X moves its anti-bot defenses, which is roughly every two to four weeks.

The basic shape

Launch a browser, log in, navigate, and scrape the DOM. A trimmed Playwright sketch:

from playwright.sync_api import sync_playwright

def grab_profile(handle: str):
    with sync_playwright() as pw:
        chrome = pw.chromium.launch(headless=False)  # a visible window dodges some fingerprint checks
        tab = chrome.new_page()
        tab.context.add_cookies(SESSION_COOKIES)      # reuse a logged-in session
        tab.goto(f"https://x.com/{handle}")
        tab.wait_for_selector('[data-testid="tweet"]')
        for card in tab.query_selector_all('[data-testid="tweet"]'):
            yield card.inner_text()

Why it fights back in 2026

X stacks several defenses:

Defense	Effect
Cloudflare WAF	IP reputation scoring, bot detection, challenge pages
Login wall	Almost nothing renders without auth since 2023
Fingerprinting	Canvas, WebGL, and audio entropy checks
Datacenter IP blocks	VPN and datacenter ranges flagged on sight
Aggressive throttling	Tight caps per account and per IP
Frequent churn	Anti-scraping logic shifts every 2 to 4 weeks

To keep a browser scraper alive you need:

• Residential proxies ($5 to $15/GB), since datacenter IPs are blocked instantly
• Stealth tooling, such as playwright-extra patches or Camoufox
• Session rotation, because login tokens lapse in roughly 6 hours
• A conservative ceiling, around 500 tweets per day per account
• Headed mode, since headless gets flagged far more often

The real bill

"Free" stops being free once infrastructure enters the picture:

Line item	Cost
Residential proxies	$50 to $200/month
Compute / servers	$20 to $50/month
Session management	Your engineering hours
Keeping pace with X's defense changes	Ongoing engineering hours

Infrastructure costs are estimated ranges, not vendor-published figures.

For 100,000 tweets a month you are looking at an estimated $100 to $250 in infrastructure plus real dev time, and it can still break next Tuesday.

Legal exposure: high

X's terms ban scraping outright:

Crawling or scraping the Services in any form, for any purpose without our prior written consent is expressly prohibited.

The terms carry a liquidated damages clause: EUR 15,000 per 1,000,000 posts pulled by automated means without permission. A 2026 draft widens that to anyone who "induces or knowingly facilitates" scraping. X has put muscle behind it too, suing Bright Data (trial set for March 2026), the Center for Countering Digital Hate, and others.

Where it shines

• No per-call API fee
• Reach to anything the browser can render
• No key or developer account needed

The tradeoffs

• Heavy infrastructure cost in proxies and compute
• Endless maintenance as X shifts defenses
• A direct terms breach with a liquidated-damages clause attached
• Fragile, fails without warning
• Real legal risk, since X litigates scrapers
• Slow next to a plain API call

Who it suits

Honestly, very little in 2026. The payoff per hour is poor against API routes. Maybe a one-off pull of a handful of tweets where standing up API access is not worth it.

---

The legal picture, briefly

For the caller, the official X API and TwitterAPIs both carry no terms-of-service exposure. Browser scraping and internal-API Python libraries breach X's terms, which attach a liquidated-damages clause of EUR 15,000 per 1,000,000 posts taken without consent. CFAA risk climbs sharply for anything behind a login wall, and since the 2023 auth requirement that is most of X.

Method	Breaches ToS?	CFAA risk?	Lawsuit risk?
Official X API	No	No	No
Managed API (TwitterAPIs)	No (for the caller)	No	No
Browser scraping	Yes	Possible (login-gated content)	Yes, X sues scrapers
Python libraries (internal API)	Yes	Possible	Lower (individual vs company)

The precedents worth knowing

X Corp v. Bright Data (2023 to 2026): X sued over scraping and resale of user data. The court tossed most of it, holding that scraping public data is protected, then X refiled narrower server-load claims. Trial lands in March 2026, with no final ruling yet.

hiQ v. LinkedIn (Ninth Circuit): the court held that scraping public data does not breach the CFAA. But X pushed most content behind a login wall in 2023, which badly weakens the "public" framing here.

Net of it: scraping genuinely public data is broadly fine under the CFAA, but scraping past a login wall is untested ground, and the EUR 15,000-per-million clause turns that uncertainty into a real dollar figure.

---

Picking a route by constraint

Rather than a flowchart, choose by the one constraint that binds you hardest:

• You need OAuth or user-context writes, or compliance forces first-party access. Use the official X API. It is the only sanctioned channel, and the price is the cost of that guarantee.
• You want the lowest cost and the fastest setup, and a third-party dependency is acceptable. Use TwitterAPIs at $0.0008 per read with proxies and retries handled for you.
• It is a low-volume personal or research build and downtime is tolerable. Reach for Twikit or Twscrape, free but liable to break.
• You are tempted by browser automation. In 2026 it rarely earns its keep once you total proxies, maintenance, and legal exposure against an API.

What 100K tweets a month actually costs

Method	Monthly cost	Setup	Upkeep
Official X API	~$500	30 min	None
TwitterAPIs	~$80	5 min	None
Browser scraping	~$150 plus dev time	Days	Weekly
Python libraries	$0	30 min	Whenever it breaks

If your real choice is a marketplace actor versus a direct API, the Apify Twitter scraper vs TwitterAPIs comparison runs both over one workload so you see the true per-1,000-tweet difference instead of the list price.

---

What developers actually report

None of this plays out in a vacuum. Developer threads and subreddits have spent two years documenting where each path cracks, and the read is consistent: the official pricing pushed a big share of builders toward alternatives, and most of those alternatives swap a per-call fee for either fragility or legal risk. The loudest complaint is cost. When reads open at $0.005 and Enterprise tiers climb into five figures a month, small teams look elsewhere, and plenty end up scraping precisely because the official API priced them out. For how those headline numbers turn into a real monthly invoice, the Twitter API cost breakdown and the question of whether the Twitter API is free are both worth a read before you commit.

You see the sentiment from working developers constantly:

https://x.com/peterevance_/status/1811455385020047631

And it is not only price. The official API changed shape repeatedly after 2023, and builders who relied on it cite that churn as the reason they walked away entirely. This thread captures it:

https://x.com/MichaelKochDev/status/1720845631541948729

The community is equally blunt about what holds up when you actually sit down to pull data. This r/Python thread on twscrape, one of the most-cited free GraphQL scrapers, gathers the practical tradeoffs people hit in real projects:

the r/Python thread on the twscrape Twitter search and GraphQL scraper from r/Python

https://www.reddit.com/r/Python/comments/13ufgvs/github_vladkenstwscrape_twitter_search_graphql/

If you are weighing the official route against a managed one, the Twitter API v2 vs TwitterAPIs comparison puts the features and pricing side by side, and the RapidAPI Twitter alternative guide explains what shifts when you route through a marketplace instead of a direct provider.

How teams get burned, and how to avoid it

Teams that regret their choice usually fell into one of two traps: they underweighted the upkeep of self-hosted scraping, or they picked on headline price and only later found the real per-1,000-tweet cost was higher once retries and failed pages were counted. The cheapest Twitter API ranking measures eight providers on observed cost rather than list price, which is the figure that bites when a pipeline runs daily. Coming off a specific incumbent, the migration guide from twitterapi.io maps the endpoints so you are not rewriting your client from scratch.

Self-hosting has its own learning curve. Even a small daily pull raises the question of which approach survives across weeks rather than one clean run, and developers compare notes on exactly that:

the r/webscraping thread on the best way to run a very small daily Twitter scrape from r/webscraping

https://www.reddit.com/r/webscraping/comments/1937al7/very_small_daily_twitter_scrape_best_way_ok_with/

For Python-first teams, a short walkthrough makes the tradeoffs concrete. This tutorial on pulling Twitter data with Python shows the request-and-parse pattern that a managed API formalizes:

https://www.youtube.com/watch?v=MF1XpFUIUMk

If browser automation is genuinely required, budget the infrastructure up front. Residential proxies, stealth tooling, and detection avoidance are all moving targets, and the best residential proxies for Twitter scraping and the Twitter bot detection guide cover the two areas where most browser scrapers fail first. Playwright documents its automation surface in the official Playwright docs, and for any account-driven flow you may also want a Twitter API key ready in case you fall back to the official API. For pulls past the recent window, the scrape tweet history guide explains why deep archive access stays the hardest data type to get cheaply.

---

A modeled cost-and-reliability comparison

The pricing table above is list price, but for a production pipeline the time-to-finish and the failure rate weigh as much as cost per call. The figures below are a model, not a published benchmark: they combine each method's per-call price with the failure rates we typically see, so read them as estimates for two common collection jobs rather than measured results.

Job A: collect 10,000 tweets from advanced search ("AI startup," last 30 days)

Method	Estimated time	Estimated cost	Estimated failure rate
Official X API	~2 min (throttled)	~$50	~0%
TwitterAPIs	~45 sec	~$10	~0%
Browser (Playwright + residential proxy)	~4 hrs	~$18 infra	~12%
Twikit	~1.5 hrs	$0	~23%

Job B: export 50,000 followers from a B2B SaaS account

Method	Estimated time	Estimated cost	Estimated failure rate
Official X API (Enterprise)	~8 min	~$500 (tier cost)	~0%
TwitterAPIs	~4 min	~$0.25	~0%
Browser scraping	Not practical at this size	$200+	>60%
Twscrape	~3 hrs	$0	~41%

Methodology: both tables are modeled estimates as of March 2026, not a measured benchmark run. Each column combines the method's per-call list price with the failure rates we typically observe, so no fixed sample-size (N) underlies the numbers. Treat the time, cost, and failure-rate figures as planning estimates to validate against your own workload.

For the follower-export job in particular, the follower export guide carries the full code path, including async batching across several accounts.

TwitterAPIs in five minutes

No developer application, no OAuth setup, no card. Register, copy the key, and run the curl below. The four steps after it take about five minutes and leave you with a working Python scraper that paginates and returns structured tweet objects at $0.0008 per call. The Python sample reuses a requests.Session for connection pooling and timeouts, and if you would rather work in JavaScript the Twitter API Node.js tutorial ports the same flow to fetch.

Step 1: grab a key

Register at /signup with an email and password. No application, no card. You start with $0.50 in credits.

Step 2: fire a search

curl -G "https://api.twitterapis.com/twitter/tweet/advanced_search" \
  --data-urlencode "query=climate tech" \
  --data-urlencode "product=Latest" \
  -H "Authorization: Bearer $TWITTERAPIS_KEY"

Step 3: read the response

import os, requests

session = requests.Session()
session.headers["Authorization"] = f"Bearer {os.environ['TWITTERAPIS_KEY']}"

resp = session.get(
    "https://api.twitterapis.com/twitter/tweet/advanced_search",
    params={"query": "climate tech", "product": "Latest", "count": 20},
    timeout=30,
)
batch = resp.json()["tweets"]
for tw in batch:
    print(tw["author"]["userName"], tw["likeCount"], tw["text"][:80])

Step 4: page through the rest

collected = list(batch)
page = resp.json()
while page.get("next_cursor"):
    resp = session.get(
        "https://api.twitterapis.com/twitter/tweet/advanced_search",
        params={"query": "climate tech", "product": "Latest",
                "count": 20, "cursor": page["next_cursor"]},
        timeout=30,
    )
    page = resp.json()
    collected.extend(page["tweets"])

That is a full scraper in around twenty lines. No browser, no proxy, no actor config. For building richer search queries (date ranges, engagement floors, media type, geo), see the advanced search operators guide.

A frank read on Python libraries in 2026

The Python options fall cleanly into two camps. Twikit and Twscrape are maintained and ride X's internal GraphQL API, while snscrape has effectively gone dark since its maintainers paused work in 2023 and X shuttered the HTML endpoints it depended on. The rundown below reflects GitHub activity as of Q1 2026 and the Python Twitter scraping discussion on Hacker News.

Twikit: the most active pure-Python library as of March 2026. It uses X's internal GraphQL API rather than a public REST surface, which makes it capable and brittle in equal measure. Install it with pip install twikit from the Twikit package page on PyPI, authenticate once, and the session caches for later runs. Throttling is enforced by X's internal systems and is undocumented; budget for somewhere around 200 to 500 requests per 15 minutes before it slows you.

Twscrape: community-maintained, well-documented, and built around an account pool that spreads requests to ease throttling. The twscrape repository on GitHub is where active issues and breakage reports land, so it is the quickest way to check whether the library is currently working. Account rotation makes it a better fit than Twikit for medium-volume research, but it still breaks when X rotates its internal token logic.

Tweepy: the official X API v2 wrapper. Fully supported, never breaks, and complete on OAuth, but it inherits the official price of $0.005 per read against $0.0008 on TwitterAPIs. For read-heavy work, that is over 6 times the per-tweet cost for the same data.

snscrape: no longer worth recommending. The project paused in 2023 and depends on HTML endpoints X has steadily closed. Use Twikit if you want a free library.

The community's honest take (Stack Overflow's Twitter API tag): free libraries are fine for low-volume academic and personal work where downtime is survivable. For anything in production where downtime costs money, pay the $0.0008 per call for a managed API.

Match the route to the data type

Choosing a route on volume alone overlooks a quieter variable: different data types differ wildly in feasibility and cost across the four methods. Follower lists are punishing on the official API (Enterprise at $42,000 a month) yet $0.0008 a call on TwitterAPIs. The map below ties each data type to its practical access path.

Search and timelines. All four methods support tweet search. The official API and TwitterAPIs return the cleanest structured rows. Python libraries work but can drop results when X reshuffles its internal ranking. Browser scrapers work but lean on session management.

User profiles. Handle, bio, follower count, and verification status are the easiest data to pull reliably, and every method handles them. The TwitterAPIs user-info response carries 16 fields out of the box, while the official API needs field expansions to match that coverage.

Followers and following. This is where the official path turns brutal on price. Enterprise opens at $42,000 a month for commercial access to large follower lists. TwitterAPIs returns the same follower data at $0.0008 per call, about 70 followers on the first page and fewer after that, which makes it the only practical choice for large follower analysis outside an Enterprise contract. The follower export guide has the implementation.

Historical data. Going back more than 7 days needs Full Archive Search on the official API (Enterprise) or equivalent third-party access. The TwitterAPIs advanced search accepts date ranges, but deep archive reach still rides the underlying infrastructure.

For workloads that span several data types, this matrix matters more than the raw per-call price. A job that needs tweets, profiles, and follower lists will be paced by the follower export, since that is the most expensive data to pull on any route.

Standing up a long-running pipeline

For a scraper that runs on a daily or hourly schedule, four operational choices outweigh which API you picked: scheduling, idempotent storage keyed on tweet IDs, alerting that fires above the isolated-429 noise floor, and a budget ceiling that catches a runaway pagination loop before it eats a month of credits.

Scheduling. Drive it from a scheduler, cron, Celery, Airflow, or a timed cloud function, rather than running scripts by hand. Manual runs miss windows and open data gaps that are painful to backfill.

Idempotent storage. Make re-runs safe: the same job twice should not double up records. Key your table on the tweet ID. TwitterAPIs returns a stable id on every tweet object.

Alerting. Pipe API errors into your logging stack and alert on a sustained failure rate above a few percent. One 429 is normal. Ten in a row means your rate-limit handling is off.

Budget guards. Set a monthly ceiling and alert at the halfway mark. At $0.0008 per call, a loop or pagination bug can chew through credits quietly if nothing catches it.

For the full production stack with these patterns wired in, the TwitterAPIs best practices guide has the detail.

Hardening a non-API scraper

Teams running Twikit, Twscrape, or browser scrapers at scale keep tripping over the same four failure modes: a single account hitting its rate limit, datacenter IPs getting blocked, session tokens expiring after about 6 hours, and headless fingerprinting by X's bot detection. The practices below target each one and can cut failure rates a lot for non-API routes.

Account pools. Run 5 to 10 accounts for any sustained job and spread requests across them to stay under per-account limits. Rotate on a 429 rather than sleeping one account.

Proxies. Residential proxies beat datacenter proxies on X by roughly 5 to 10 times on success rate. Bright Data and Oxylabs are the two most-cited residential providers in developer circles as of 2026, though X has sued Bright Data over data resale (a separate matter from proxy supply).

Session refresh. Twitter auth_token cookies expire after roughly 6 hours idle. Refresh on a 4-hour cadence for long jobs.

Headed over headless. X's detection has gotten sharp at flagging headless Chrome through canvas entropy, WebGL renderer strings, and audio-context anomalies. A real visible window dodges most of those fingerprints but needs a desktop environment. Camoufox, a Firefox fork, is the current community pick for stealth.

None of this touches an API route. A managed scraper API absorbs all of it server-side.

Get started

The quickest path is TwitterAPIs: register at /signup, take the $0.50 in free credits with no card, and make your first call inside five minutes. The links below cover the setup for every route in this guide.

• Official X API: console.x.com
• TwitterAPIs: Sign up free ($0.50 in credits, no card)
• Full pricing: TwitterAPIs Pricing
• Cost calculator: Twitter API Cost Calculator
• Advanced search operators: Full query syntax guide
• Python tutorial: Code for every endpoint
• Scraping best practices: The production guide
• Follower export: Export any account's followers at $0.0008/call

---

Legal information in this article is for educational purposes only and does not constitute legal advice. Consult a lawyer for your specific use case. Sources: X Terms of Service, X Corp v. Bright Data, hiQ v. LinkedIn. Data verified March 2026.