Sticky sessions

A sticky session asks the gateway to reuse a compatible exit for related requests. It is useful when a workflow expects continuity across navigation, authentication, or a short transaction.

Session identity

Add sid-{session_id} to the package username. Reuse the same value for the requests that belong together.

Session lifetime

Add ttl-{seconds} to bound how long the routing preference can remain active.

package-elite-country-us-sid-checkout-42-ttl-1800

Session lifecycle

1. Generate an opaque session ID in your application; do not use an email address or another personal identifier.
2. Keep the targeting tokens, session ID, and package stable across the workflow.
3. Stop reusing the ID when the workflow completes or its own lifetime expires.
4. Generate a new ID for an independent user journey.

What can change the exit

• the requested TTL expires;
• the upstream exit becomes unavailable;
• the connection cannot satisfy the original targeting;
• the package, location, ASN, or ISP tokens change;
• deployment-level session controls revoke or replace the session.

Sticky does not mean dedicated

Session routing is continuity-oriented, not ownership of a residential IP. Applications must recover when a new compatible exit is selected.

Choose a session granularity

Workflow	Good session key	Avoid
One checkout	Random ID per checkout	One global ID for every customer
Browser automation task	Random ID per task	Reusing an ID after task completion
Account health check	Random ID per account run	Putting the account email in sid
Stateless collection	No session token	Adding sessions without a continuity need

Active sessions can also be inspected or revoked through the API. See the generated API Reference for the /sessions operations.