# Twitter Proxies: Do You Need Them to Scrape X? Canonical: https://www.twitterapis.com/answers/do-you-need-proxies-to-scrape-twitter Description: Pooled reads need no proxy at all. Only the user_login route takes a proxy_url, where a residential address is strongly advised. Reads run $0.0008 a call. Generated: 2026-08-26T06:52:18.938Z ---[Pricing](/pricing)[Docs](https://docs.twitterapis.com)[Blog](/blogs) Compare and Tools [MCP Server](/mcp)[Integrations](/integrations)[Language Clients](/sdk)[Free Tools](/tools)[Twitter ID Finder](/tools/twitter-id-finder)[Twitter API Cost Calculator](/twitter-api-cost-calculator)[Twitter Search API](/twitter-search-api)[Twitter Followers API](/twitter-followers-api)[Twitter Scraper](/twitter-scraper)[Twitter API Use Cases](/twitter-api-usecases)[Twitter API Rate Limits](/twitter-api-rate-limits)[Twitter Unofficial API](/twitter-unofficial-api)[Twitter Free API](/twitter-free-api)[Twitter API Alternatives](/twitter-api-alternatives)[TwitterAPIs vs Tweepy](/twitterapis-vs-tweepy)[TwitterAPIs vs RapidAPI](/twitterapis-vs-rapidapi)[TwitterAPIs vs GetXAPI](/twitterapis-vs-getxapi) Company [About](/about)[Status](/status)[Affiliates](/affiliates)[Trust](/privacy-and-data-handling)[Changelog](/changelog)[Contact](/contact) [Start Free](/signup) 1. [Home](/) 2. /[Answers](/answers) 3. /Do you need proxies to scrape Twitter? # Do you need proxies to scrape Twitter? Last updated August 24, 2026 For pooled reads, no. Search, profiles, timelines and followers are fetched by our infrastructure, so no address of yours reaches x.com and nothing in the request takes a proxy. One exception exists: POST user/user\_login accepts proxy\_url and the reference strongly recommends a residential one, since datacenter logins draw challenges. Reads stay flat at $0.0008 a call. Every rate here is the pricing TwitterAPIs publishes. The billed rate is $0.0008 per call; $0.04 per 1,000 tweets is derived from it at a full 20-tweet page, which is the default page size rather than a guaranteed yield (source: [twitterapis.com/pricing](/pricing)). ## The answer depends entirely on whose address is talking to X Run the scraper yourself and yes, you need proxies, because your own egress address is the identity X throttles and eventually blocks. Call a hosted endpoint instead and the question stops applying, since the request that reaches X leaves our infrastructure rather than your laptop or your cloud instance. There is no pool for you to buy, rotate or babysit. That covers every pooled read on the surface, which is most of what people mean by scraping: search, profiles, timelines, follower lists, media. One narrow exception survives, and it is the only place an address field appears in the request contract at all. Registering your own X account as a session is that exception, and telling the two cases apart is most of what this page is for. ## What a proxy is actually doing inside a self-managed scraper A proxy does exactly one job: it changes which address X sees. Automated browsing from a single address gets recognised quickly, and the response is a slowdown first and a cut-off after, frequently within hours of a heavy run. So you buy a pool, spread requests across it, retire addresses that start returning challenges, and top the pool back up. None of that is scraping logic. It is infrastructure you maintain so the scraping logic gets a chance to run at all. Residential addresses survive longer than datacenter ones because they read as ordinary consumer traffic, which is why that tier exists and why it is the expensive tier. The pool is also the part that quietly sets your real throughput, and nobody publishes that number for you. ## A hosted route deletes the layer instead of managing it TwitterAPIs owns the request infrastructure, the anti-bot layer and the endpoint upkeep, and hands back structured JSON. Concretely, three blocks of your code stop existing: the proxy configuration and rotation, the retry loops wrapped around bans and stalls, and the HTML parsing that turned a rendered page into records. What replaces all of it is a GET against a documented path carrying Authorization: Bearer YOUR\_API\_KEY, and a JSON body you read fields off. The header x-api-key with the same value is accepted too if that suits your stack better. Nothing in a read request takes an address, a user agent or a pool handle, because on this side of the call none of those are yours to supply. ## Pooled reads, and the four null fields that prove it Most routes here are described in the reference as pooled reads served by our account pool, meaning a rotating account of ours makes the upstream request. That has a visible consequence worth designing around. Community Info returns role, can\_join, is\_pinned and viewer\_relationship\_type as null on every single response, because each of those four answers a question about the account that made the call, and the caller is a pool account rather than you. The keys are kept rather than stripped, so it stays obvious that X sends them. Read that as the signature of a pooled read: everything about the object itself is populated, and anything caller-relative is deliberately empty. When you need caller-relative truth, what you need is a session, not an address. ## The one call where an address is still recommended: user\_login POST user/user\_login mints an X session from a username and password, and it takes an optional third parameter, proxy\_url, described in the reference as strongly recommended. The reason is specific rather than general: credential logins from datacenter IPs are commonly challenged by X. A residential address makes the sign-in look like a person connecting from home, which is the exact distinction the challenge is drawing. This call costs $0.01 and is billed only when a login actually succeeds, so an attempt that dies on a challenge is not charged as one. If you can copy cookies out of a browser tab instead, prefer customer/session, which the reference recommends over credential login precisely because it avoids the challenge path. ## customer/session takes an address too, plus a user agent Registering cookies is the preferred way to attach your own account. customer/session takes auth\_token and ct0 in the JSON body, never the query string, and two optional fields matter here. user\_agent defaults to a current Chrome string. proxy\_url accepts an HTTP or SOCKS URL written as http://user:pass@host:port and defaults to direct, so setting it routes that session's traffic through egress you control instead of ours. The registration call itself is free and stores the pair once, after which every Session Read, Write Action and Direct Message route runs as your account. Any single call can also carry the pair inline as the x-auth-token and x-ct0 headers, which skips stored state entirely. ## One published ceiling replaces the rotation arithmetic With a pool you never learn your limit, you discover it by getting blocked, and the number moves with the pool's health. Here the limit is written down and identical on every route: 600 requests per minute and 20 concurrent in flight, per key. Cross either bound and you get a 429 carrying a Retry-After header in whole seconds, so backoff becomes one branch reading one header rather than a heuristic wrapped around silence. Every response also carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. There is no per-endpoint quota, no fifteen-minute bucket and no tier to buy past, so capacity planning is arithmetic against one number and your credit balance rather than a guess about how many addresses to hold. ## What you stop maintaining, which is where the real bill sits A free library downloads for nothing and then bills you in hours. Reverse-engineered clients read X's internal endpoints, so any change the site ships breaks them. snscrape has sat mostly dead since 2023, and the forks people still run demand constant patching. A scraper that fails at two in the morning costs more than an endpoint that simply keeps answering. Proxy spend is only the visible half of that. The invisible half is the engineer who owns rotation, challenge handling, parser repair and the pager. Moving to a hosted route usually touches one file, because the shape you were assembling by hand arrives already assembled, and the code you delete is the address handling and the parsing rather than your actual analysis. ## Cost, stated without inventing anybody else's numbers A standard read is $0.0008 and returns roughly twenty posts, which puts a thousand posts near four cents. New accounts open with $0.50 in credit and no card, worth about 625 calls or roughly 12,500 posts, enough to run a real pilot before attaching payment. Against that, the honest line for the free libraries is not a price at all: the licence is $0 and you fund the proxies and the compute yourself, at whatever your provider charges. We publish no figure for that, because it is not ours to publish and it moves with the tier you buy. Compare the two on total cost including the engineering time, not on the licence line, which is the only line where free wins. $0.0008 a call, per our published pricing. ## Self-managed scraping against a hosted API, layer by layer Layer you own Self-managed scraper TwitterAPIs Egress addresses You buy and rotate a pool, and you fund it Ours, and no proxy\_url on any pooled read Anti-bot handling Yours to solve again after every X change Part of the request layer we run Parsing Rendered HTML or internal endpoints, reshaped constantly Structured JSON off a documented path Retry and backoff Hand-written around blocks and silent stalls 429 carries Retry-After in whole seconds Throughput ceiling Unpublished, discovered by getting blocked 600 requests a minute, 20 concurrent, per key Acting as your own account Your cookies and your egress, always proxy\_url on user\_login, residential recommended Cost model $0 licence, you fund proxies and compute $0.0008 a call, near four cents per 1,000 posts > The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. MDN Web Docs, HTTP 429 Too Many Requests. [Source](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429) ## Questions and answers Do I need a proxy to call the search endpoint? No. Search, profiles, timelines, follower lists and media are pooled reads, and the upstream request leaves our infrastructure rather than yours. The request contract for those routes has no address field, no user agent and no pool handle, because none of them are yours to set on this side. You send a query and a Bearer header, and you read JSON back. Your own connection never touches x.com at any point in that exchange. Which calls actually accept a proxy\_url parameter? Two of them. POST user/user\_login accepts proxy\_url alongside username and password, and the reference calls it strongly recommended. POST customer/session accepts proxy\_url as well, plus an optional user\_agent, and defaults to direct when you leave it out. Both are about attaching your own X identity rather than reading public data, which is exactly the dividing line: pooled reads take no address, account-acting session setup can take one. Why does logging in from a datacenter address get challenged? The reference states it plainly: credential logins from datacenter IPs are commonly challenged by X. A sign-in is the moment the platform cares most about whether a person is present, and an address block belonging to a cloud provider is weak evidence for that. A residential address reads as an ordinary home connection instead. That is why proxy\_url exists on the login route and appears nowhere in the read surface at all. Is residential genuinely better than datacenter here? For the credential login, yes, and that is the only place it is recommended. The documentation says to log in from a residential proxy because datacenter origins draw challenges. For every pooled read the comparison is moot, since you are not supplying an address at all. We publish no per-provider prices or success rates for proxy tiers, because those figures belong to the vendor selling them rather than to us. Does owning more addresses raise my rate limit? Not here. The ceiling is per API key rather than per address: 600 requests a minute and 20 concurrent in flight. Buying more egress does not lift it, and running everything from one machine does not lower it. Past either bound the answer is a 429 with Retry-After in whole seconds. Under a self-managed pool the opposite holds, where usable capacity really is a function of how many healthy addresses you hold. Can I still route traffic through my own network if policy demands it? For session traffic, yes. proxy\_url on customer/session sends that session's requests through an HTTP or SOCKS endpoint you control, written as http://user:pass@host:port, and it defaults to direct when unset. Pooled reads offer no equivalent hook, because the upstream call there is made by a pool account on our side. So the answer splits by route rather than being one blanket policy across the whole surface. What happens to my own account if I scrape without a proxy? Pointing a self-run scraper at x.com from a fixed address invites throttling first and a block after, and a login-driven scraper puts the account itself at risk of being locked. Reading through a hosted endpoint moves that exposure off your infrastructure entirely, since neither your address nor your credentials are part of the transaction. That separation matters more in practice than any per-call price difference between the two approaches. Will a proxy help my scraper survive an X update? No, and conflating the two is common. A proxy solves who you appear to be. A site change breaks what you parse. Reverse-engineered clients read internal endpoints, so a shipped change snaps them no matter how healthy the pool is underneath. That is a separate maintenance stream you own forever, and it is why a free library's true cost shows up in engineering hours rather than on any invoice. How much of a scraping budget usually goes on proxies? We cannot answer that with a number, because we do not sell proxies and quoting a rate we never charge would mean inventing one. What can be said is the shape of it: with a free library the licence is $0 and the addresses and compute are yours to fund, while with a metered read the line item is $0.0008 a call with no separate infrastructure bill sitting underneath it. Can I test this before building any egress at all? Yes, and that is the normal path. Signup hands you $0.50 in credit with no card, about 625 calls or roughly 12,500 posts, and not one of those calls needs an address from you. Send a GET with Authorization: Bearer and your key, read the JSON, and check the shape against what you expected. If it fits you never build the proxy layer, and if it does not you have spent nothing. ## Keep reading - [Twitter scraper API](/twitter-scraper?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-do-you-need-proxies-to-scrape-twitter) - [Unofficial Twitter API](/twitter-unofficial-api?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-do-you-need-proxies-to-scrape-twitter) - [Rate limits and the 429](/twitter-api-rate-limits?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-do-you-need-proxies-to-scrape-twitter) - [Per-call pricing](/pricing?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-do-you-need-proxies-to-scrape-twitter) - [Is it legal to scrape Twitter?](/answers/is-it-legal-to-scrape-twitter?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-do-you-need-proxies-to-scrape-twitter) - [How do you log in to X with an API?](/answers/how-to-log-in-to-x-with-an-api?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-do-you-need-proxies-to-scrape-twitter) - [Getting tweets from Python without a proxy pool](/answers/how-to-get-tweets-with-python?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-do-you-need-proxies-to-scrape-twitter) ### Start with $0.50 in free credits No credit card. Roughly 12,500 tweets to test every endpoint. [Get your API key](/signup?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-do-you-need-proxies-to-scrape-twitter)[See pricing](/twitter-scraper?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-do-you-need-proxies-to-scrape-twitter) [ TwitterAPIs](/) The cheapest pay-as-you-go Twitter and X API. $0.0008 per call, which works out to $0.04 per 1,000 tweets on a full 20-tweet page. No subscriptions and no developer account. ## Product / API - [Pricing](/pricing) - [Pay-Per-Use Pricing](/pay-per-use-pricing) - [Cost Calculator](/twitter-api-cost-calculator) - [Rate Limits](/twitter-api-rate-limits) - [MCP Server](/mcp) - [Integrations](/integrations) - [Language Clients](/sdk) - [Changelog](/changelog) - [Status](/status) ## Developers - [Documentation](https://docs.twitterapis.com) - [API Reference](https://docs.twitterapis.com/docs/reference/search/tweet-advanced-search) - [User Info](https://docs.twitterapis.com/docs/reference/user-reads/user-info) - [User Tweets](https://docs.twitterapis.com/docs/reference/user-reads/user-tweets) - [Advanced Search](https://docs.twitterapis.com/docs/reference/search/tweet-advanced-search) - [Verified Followers](https://docs.twitterapis.com/docs/reference/follower-graph/user-verified-followers) ## Resources / Compare - [Answers](/answers) - [Reviews](/reviews) - [Free Tools](/tools) - [Twitter ID Finder](/tools/twitter-id-finder) - [Get a Twitter API Key](/twitter-api-key) - [Official X API Comparison](/twitter-api-pricing) - [Twitter API Use Cases](/twitter-api-usecases) - [Twitter API Alternatives](/twitter-api-alternatives) - [Twitter Unofficial API](/twitter-unofficial-api) - [Twitter Free API](/twitter-free-api) - [TwitterAPIs vs twitterapi.io](/twitterapis-vs-twitterapi-io) - [TwitterAPIs vs GetXAPI](/twitterapis-vs-getxapi) - [TwitterAPIs vs TweetAPI](/twitterapis-vs-tweetapi) - [TwitterAPIs vs TwexAPI](/twitterapis-vs-twexapi) - [TwitterAPIs vs RapidAPI](/twitterapis-vs-rapidapi) ## Legal - [About](/about) - [Security](/security) - [Trust](/privacy-and-data-handling) - [Terms of Service](/terms-of-service) - [Affiliates](/affiliates) - [Contact](/contact) - [Jobs](/jobs) © 2026 TwitterAPIs. All rights reserved. TwitterAPIs is an independent third-party API for developers and researchers. Not affiliated with, endorsed by, or sponsored by X Corp. All systems operational