Docs/Core concepts/Intent routing

Intent routing

Humans know the difference between rotating residential and static ISP. Agents know what they are trying to do. Intent routing maps the second to the first: declare the task, and the platform picks the proxy strategy.

The three intents

explore — broad search and discovery. Routed to economical rotating pools; each connection may use a different exit.
session — logged-in, stateful work. Routed to sticky residential exits; combine with a session ID to pin one exit for the task.
checkout — transactions and other trust-sensitive operations. Routed to static-ISP-grade exits with the cleanest reputation.

gateway username examples

# Broad discovery — cheap rotating exits:
user-sk_test_xxx-type-explore

# Logged-in, multi-page flows — sticky residential:
user-sk_test_xxx-type-session-session-task42

# Transactions / checkout — static ISP grade:
user-sk_test_xxx-type-checkout

# All via the same endpoint:
http://...:[email protected]:7777

What the router does for you

Behind the single endpoint the routing engine selects an upstream supplier and pool per intent and geography, isolates bad exits automatically, and hot-switches suppliers on failure. Failed TCP/TLS connections and plaintext HTTP requests are retried and rerouted automatically.

The honest boundary

For HTTPS the gateway only sees the tunnel — domain, bytes, connection result. Application-layer failures inside an established tunnel (a 403, a CAPTCHA page) are invisible to the router and cannot be auto-retried. If you need the platform to handle those too, that is what Managed Fetch (coming soon) is for.

Intent affects routing and exit quality, and the pool it lands on determines the per-GB rate billed. When a connection targets a Persona, the Persona's own exit always wins over the intent parameter.

Next steps

Personas

Persistent identities for session and checkout work.

curl / gateway params

Full username syntax with examples.