We are Geonode and we sell proxies, so this is the disclosure that matters: X is the platform where we can justify selling you the least. Its terms prohibit scraping in language that leaves no interpretive room, its robots.txt disallows every crawler it has not specifically named, and the official API is the sanctioned route. We are not going to write a guide to circumventing that, and if you were hoping for one, this article will disappoint you. There is a real and narrow set of jobs where proxies are appropriate — checking your own ad delivery by region, verifying what publicly visible content looks like from different countries, brand-safety monitoring at modest volume — and those are covered properly below. For everything else the honest answer is the API or nothing, and we would rather say so than take the money.
X's Terms and robots.txt Are Unusually Explicit
Most platforms discourage scraping in general language. X does something different.
The Terms of Service state under acceptable use: "You may not access the Services in any way other than through the currently available, published interfaces that we provide. For example, this means that you cannot scrape the Services without X's express written permission".
And in the enumerated prohibitions, an explicit parenthetical: "(NOTE: crawling or scraping the Services in any form, for any purpose without our prior written consent is expressly prohibited)".
Read "in any form, for any purpose" carefully. That phrasing forecloses the arguments people usually reach for — that public data is fair game, that read-only access is different, that research is exempt. X has written the exclusion broadly and deliberately. The same clause also covers attempts to "circumvent, manipulate, or disable systems and Services".
The robots.txt at x.com/robots.txt matches. It grants specific allowances to named crawlers — Googlebot and Bingbot share a group, facebookexternalhit has its own — and then, for everything else:
User-agent: *
Disallow: /
Everything. There is also a Crawl-delay: 1 and a set of explicit blocks on AI and social crawlers: Google-Extended, FacebookBot, Discordbot, and Meta's meta-webindexer, meta-externalagent, meta-externalads and meta-externalfetcher all receive Disallow: *.
Even the named search crawlers are restricted from the interesting parts. /search/realtime, /search/users, /*/followers, /*/following, /*/likes, /*/retweets, /*/media and /*/analytics are all disallowed — which is to say, precisely the paths a social-data pipeline would want.
Two honest conclusions follow. First, this is not a grey area; X has removed the ambiguity on purpose. Second, robots.txt is a request rather than an enforcement mechanism, and the practical consequence of ignoring it is account and access restriction rather than anything more dramatic. That is a business risk, and you should price it knowingly rather than pretend it is not there.
The Official Route and Its Costs
The sanctioned path is the X API through the developer portal.
We are not going to quote prices here, and the reason is worth stating: X's developer portal requires JavaScript and authentication, so we cannot verify current pricing from an official page. The figures circulating in search results come from third parties, they disagree with each other, and this blog does not repeat unverified pricing as fact. What we can tell you structurally is that the pricing model was restructured — moving away from the fixed monthly tiers many developers remember toward usage-based billing, with enterprise access by application. Check the developer portal directly and get the current numbers from X.
What is verifiable is the Developer Agreement and Policy, and it contains constraints that surprise people who assume API access means data freedom:
Redistribution is capped. Developers may provide "up to 500 public Posts Objects and/or User Objects to each person who uses your service on a daily basis if this is done via non-automated means (e.g., download of spreadsheets or PDFs)", with larger volumes requiring written permission from X.
Academic sharing is narrow. Academic researchers "are permitted to distribute Post IDs and/or User IDs solely for the purposes of non-commercial research on behalf of an academic institution", subject to X approval in writing.
Write actions have their own rules. Services performing write actions "must follow the Automation Rules": explicit consent before automated replies or direct messages, immediate compliance with opt-out requests, and never performing "bulk, aggressive, or spammy actions, including bulk following" or posting "identical or substantially similar content across multiple accounts".
That last set is the one that matters for a large share of proxy demand. The platform has specifically prohibited the multi-account posting patterns that people buy proxies to enable, in its developer terms, in plain language.
So the honest comparison is not "API versus proxies at a lower price". It is "sanctioned access with documented limits" versus "unsanctioned access with the same limits plus enforcement risk". Cost is a factor. It is not the only one.
The Legitimate Jobs Left for Proxies
Narrower than the search volume implies, and real.
Geographic verification of your own advertising. You bought placement in specific countries. Confirming delivery requires appearing to be in those countries, and no API tells you what a user in São Paulo actually sees. This is checking your own spend, it does not involve automated collection at volume, and it is the cleanest case on the list.
Brand-safety and adjacency checks. Seeing what appears next to your content in different regions. Same reasoning: low volume, geography-dependent, concerns your own brand.
Regional content availability. Whether something is visible, restricted or withheld in particular jurisdictions. X publishes some of this in its transparency reporting, but per-item checks require a regional viewpoint.
Accessing X from a network that blocks it. A corporate or campus firewall filtering the site is a network problem, not an X problem, and it raises no terms question at the platform end.
Notice what these have in common: low volume, geography as the point, and no bulk collection. They are proxy-shaped problems. Bulk data collection is not on the list, because the terms above put it outside what we will help with.
Which Proxy Type for Which Job
| Job | Type | Why |
|---|---|---|
| Ad delivery verification | Residential | Must look like a real viewer in that country |
| Brand-safety adjacency checks | Residential | Same — the feed differs by viewer |
| Regional availability checks | Residential or mobile | Mobile if app-specific behaviour matters |
| Getting past a network filter | Datacentre | Cheapest, and no platform-side question |
Residential dominates this list because every legitimate job here depends on being seen as an ordinary viewer somewhere specific. A datacentre address in Brazil is in Brazil and is not a Brazilian consumer, and for feed composition that difference is the entire point.
Two technical realities regardless of type.
X is heavily client-rendered. The initial HTML response is largely a shell. Anything you do will need a browser or an interface that returns structured data — which, for the sanctioned path, is the API.
Logged-out and logged-in views differ enormously. Much of the platform is gated. A geographic check performed logged-out is measuring a different thing from what your audience sees, and reconciling that is harder than it sounds.
What to Look For in a Provider
Criteria that survive longer than any brand ranking.
Geolocation you can verify before committing. Test with a real trial against more than one geolocation database, and — for the ad-verification case — against what the platform actually serves you, which is the only test that matters. Databases disagree; the platform's view is the one you are buying.
City-level targeting if your campaigns are city-level. Country granularity is standard. Anything finer varies wildly by provider and by location, and a coverage map is not evidence.
Session control. Holding one exit address across a sequence of requests matters for anything multi-step. Per-request rotation is right for some jobs and actively harmful for others.
Pricing model matched to your workload. Traffic-priced and per-IP pricing suit different shapes of usage. Ad verification is typically low volume across many locations, which favours traffic pricing. Sustained monitoring from a few fixed locations favours per-IP. Work out your shape before comparing headline rates, because the headline rates are not comparable.
Honest sourcing of the residential pool. Ask how the network is assembled and whether the people carrying your traffic consented. Evasion is an answer. This is an ethical question first and a stability question second — and, following the enforcement action Google's threat intelligence team announced against a network of interlinked resellers in January 2026, a legal one too.
A trial with enough volume to prove something. Not a hundred requests. Enough to see success rates across your actual target locations over several days.
Our Pricing and Where It Is the Wrong Shape
From our pricing page, checked September 2026 — verify before purchase.
Residential traffic starts at $0.79/GB, dropping to $0.50/GB above 100 GB and $0.27/GB above 1 TB. New accounts receive 1 TB of residential traffic free. Datacentre traffic starts at $0.14/GB, billed by traffic rather than per IP. ISP addresses are $1.25/IP, and there is an unlimited residential plan at $1,800/month.
Where that is wrong for you:
Low-volume ad verification may not justify any purchase. If you check ad delivery in four countries once a week, that is a trivial amount of traffic. The free tier covers it and you should not be planning a spend at all. We would rather you used the trial and left.
Concentrated, high-volume monitoring from few locations is cheaper elsewhere. Our residential pricing is per gigabyte. If you push a lot of traffic through a handful of addresses, per-IP pricing is the model that fits and you should buy from someone offering it.
Bursty seasonal usage loses money with us. Traffic does not roll over month to month. Campaign work that is heavy for two weeks a quarter will pay for capacity it burns. Look for a provider whose traffic does not expire.
Browser-based work eats bandwidth fast. X requires rendering, rendering fetches every asset, and video assets are large. Budget several times what a raw HTTP estimate suggests, and block images and media at the browser level where your check does not need them.
Practical Setup Notes
Make locale and geography agree. A Japanese exit address with en-US language headers and a European time zone is a combination no real viewer produces, and feed composition responds to language settings independently of address.
Verify by content, not by IP lookup. For geographic work, the test is whether regionally distinct content actually differs. If a Brazilian exit shows you the same trends as your desk, the geolocation is not landing regardless of what any lookup service reports.
Hold sessions across multi-step checks. Rotating mid-sequence produces an incoherent history.
Instrument by location, not in aggregate. A pool that works in eight countries and fails in one reads as healthy in an averaged metric. This is the silent-failure pattern we wrote about in why testing proxies matters.
Respect Crawl-delay: 1. X publishes it. Even for the narrow jobs above, pacing your requests at least that slowly is both polite and sensible.
When Not to Buy X Proxies at All
The longest section here, deliberately.
When you want bulk data. The terms prohibit "crawling or scraping the Services in any form, for any purpose" without written consent. The API is the route. If the API's cost or limits do not work for your project, the honest conclusion is that the project needs rethinking, not that you need a different address.
When you want to run many accounts. X's developer terms specifically prohibit "bulk, aggressive, or spammy actions, including bulk following" and posting "identical or substantially similar content across multiple accounts". This is the largest single source of demand for the search term and we are not the vendor for it.
When your volume is tiny. Checking a few things from a few countries occasionally does not need a plan. Use a free tier and stop.
When the API covers you. Sanctioned access with documented limits beats unsanctioned access with the same limits plus risk, at a fairly wide range of prices.
When you have not built anything yet. Bandwidth without a pipeline to spend it is a subscription to nothing.
When you are a researcher. X's developer terms carry specific provisions for academic researchers distributing Post IDs and User IDs for non-commercial institutional research, subject to written approval. Go through that route. It exists, and building a scraper instead forfeits the standing that route gives you.
People Also Ask
Is scraping X (Twitter) allowed?
No. The Terms of Service state you "cannot scrape the Services without X's express written permission", and elsewhere note that "crawling or scraping the Services in any form, for any purpose without our prior written consent is expressly prohibited". The robots.txt disallows every crawler not specifically named. This is not ambiguous.
Do I need proxies for the X API?
No. The API is accessed with credentials over ordinary connections and has its own rate limits, which proxies do not change. If you are hitting API limits, the answer is a different access tier, not a different IP address.
What does X's robots.txt allow?
Named crawlers such as Googlebot, Bingbot and facebookexternalhit get specific allowances, with the interesting paths — search, followers, following, likes, retweets, media, analytics — disallowed even for them. For everything else the rule is User-agent: * / Disallow: /. It also blocks several AI and social crawlers explicitly and sets Crawl-delay: 1.
What proxies work best for X?
Residential, for the legitimate geography-dependent jobs, because the point of those jobs is to see what an ordinary viewer in a place sees. Datacentre is fine and cheaper for getting past a network filter, where the platform is not the obstacle.
Can I use proxies to manage multiple X accounts?
We will not help with this. X's developer terms prohibit bulk actions and posting substantially similar content across multiple accounts, and enforcement takes the accounts with it. Authorised multi-account management for legitimate purposes runs through X's own tooling.
How much does the X API cost?
X restructured its pricing away from the fixed tiers many developers remember, and its developer portal requires authentication and JavaScript, so we cannot verify current figures from an official source. Third-party numbers in search results disagree with each other. Check the developer portal directly.
Can I scrape X for academic research?
Not without permission — the terms say "for any purpose". X's developer agreement does have specific provisions for academic researchers to distribute Post IDs and User IDs for non-commercial institutional research with written approval. That is the sanctioned route and it is worth pursuing.
Will a residential proxy stop X from detecting me?
No, and anyone claiming otherwise is overselling. Address type is one signal among many; account history, device characteristics, behavioural patterns and timing all contribute. Residential addresses raise fewer flags than datacentre ones. That is the honest claim, and it is not the same as undetectable.
Wrapping Up
We set out to write a proxy buying guide and the terms of service made it a different article. That is the honest outcome, and burying it would have been the dishonest one.
X prohibits crawling and scraping "in any form, for any purpose" without written consent, disallows every unnamed crawler in robots.txt, and specifically forbids in its developer terms the multi-account patterns that drive most demand for this search. Against that, the API is the sanctioned route, and its constraints are documented rather than discovered.
What remains for proxies is genuine but narrow: verifying your own advertising reaches the regions you paid for, checking brand adjacency by market, confirming regional availability, and getting past a network that filters the site. For those, residential addresses with verifiable geolocation are the right purchase, session control matters more than raw speed, and the volumes involved are small enough that a free trial may be all you ever need.
For anything larger, the answer is the API — and if the API does not fit the project, that is information about the project rather than a problem to route around.