Introduction

bytetourist is a proxy & scraping network. bytetourist runs its own fleet of nodes (datacenter machines on cloud providers, plus residential edges) that make the final outbound HTTP call, with a central router that sends each request to the right node using one of twelve selection strategies.

It is the layer that scraping APIs and “web unblockers” rent. You use it with an API key and pay per operation in credits.

Who it’s for

Scraping & data teams who want datacenter egress with real routing control and country/region targeting, not a single rotating-proxy endpoint.
Anyone who needs geo-targeted, fingerprint-consistent outbound requests at scale, with per-tenant quotas and metering built in.

Key concepts

Everything you need to use bytetourist comes down to a few ideas:

Concept	What it means
node	An edge: a machine bytetourist runs that makes the final outgoing call from its own IP, either datacenter or residential (see IP type).
fleet	All the nodes bytetourist runs, across providers and regions. They’re provisioned, healed, and retired automatically.
targeting	Constrain which node serves a request by country and region.
strategy	How a node is picked from the eligible set: twelve strategies, chosen per request.
session	With the `session_affinity` strategy, keep a series of requests on the same node for multi-step flows (see Sessions).

You reach the whole thing as a standard HTTP proxy: point your client at it, send your API key, and encode targeting right in the request. For HTTPS, the proxy re-signs each site’s certificate so it can route the request; your client must accept that certificate (-k, or trust the bytetourist CA). See HTTPS targets.

How it compares

bytetourist sits one layer below scraping APIs like Firecrawl. Those tools turn a URL into clean data but buy their proxy bandwidth. bytetourist is the egress network itself, and a Scrape API (markdown + structured extraction on top of the same edges) is on the roadmap.