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.

Without a session ID, each new connection is eligible for rotating selection. Rotating behavior permits a different exit but does not guarantee a new IP on every request.

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.

The same package, targeting, and opaque session ID resolve consistently across multiple gateway servers. Applications can therefore use one credential pattern behind DNS or load-balancer distribution without choosing a specific gateway for session continuity.

For generated credentials, session.ttl is measured in seconds and accepts 30 through 86400 in the current public contract. Omit the session object when you want rotating eligibility. There is no separate setting for a minimum interval between rotations.

What can change the exit

• the requested TTL expires;
• the upstream exit becomes unavailable;
• the connection cannot satisfy the original targeting;
• the package, location, or ASN 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

The public /sessions list and delete operations are currently unavailable and return 403 for authenticated callers. Do not build session inspection or revocation around them. Sticky credentials and their TTL still work independently of those management endpoints; start a new routing session with a new session identifier when your workflow requires it. For provider health and retry semantics, see routing and failure behavior.