Skip to main content
Reuse a sticky session, request a lifetime, and generate session IDs for workers. A sticky session asks the gateway to keep an exit IP for related requests. Use it when a workflow needs a consistent visitor identity across pagination, form submissions, or an authenticated session. The session lives at the gateway. The SDK builds its parameters; it does not store browser cookies, keep connections alive, or reserve a dedicated IP. The examples below assume the credentials and dependencies from your Python, Rust, or Go quickstart. Rust and Go snippets belong inside a function that handles results or errors.

Create a sticky session

Build a configuration and attach a session ID. Reuse the resulting object for related requests.
Pass held to your HTTP client using the same helper as in the quickstart. If you create a new session object, update the client’s proxy configuration too. An existing client will not automatically switch to a new SDK object.

Request a session lifetime

Add a ttl parameter before creating the session. These alternatives replace the earlier initialization and request ten minutes:
Use lowercase units. The SDK repositories document 1m, 10m, 10h, and 24h as accepted examples. The product’s sticky-session limit is up to 24 hours, subject to the exit remaining available. Setting a lifetime does not guarantee that the original IP will remain online for that period. See How sticky sessions work for product behavior and duration settings.

Keep the parameters consistent

A session identity depends on more than its ID. In particular, changing the location, proxy pool, or filter can select a different identity even if you reuse the same sid. Build the configuration once for a workflow and reuse it. To change it deliberately, create a new object:
These calls return new objects. They do not modify held, update a running browser, or transfer application cookies to another session.

Generate session IDs for workers

Use sessions to generate configurations with separate random session IDs:
Assign one configuration to each worker and keep it for that worker’s workflow. The helper generates session IDs; it does not start workers or create simultaneous connections. Distinct IDs should not be treated as a guarantee of five unique or dedicated public IPs. Session IDs cannot contain - or whitespace. For example, use worker01, not worker-01. The generated IDs avoid these characters.

Use a configuration without a sticky session

Remove sid and any sticky-session lifetime when you no longer want to request a pinned identity:
A configuration without sid does not request a sticky session. When testing rotation, consider your client’s persistent connections: two application requests can reuse an existing tunnel. Verify the exit with actual requests rather than assuming that each SDK object or client request creates a new connection.

Understand when an IP can change

Sticky sessions are different from the No rotating mode and from ISP proxies, which are a separate product.

Next steps