Sticky session
A rotating-proxy feature that keeps you on the same exit IP for a set duration so a multi-step task can complete without the address changing underneath it.
A sticky session is rotation with a hold. On a pool that would otherwise give you a different exit on every request, it pins one address to you for a defined window so a sequence of requests arrives looking like one returning visitor rather than a crowd of strangers.
It exists to resolve a genuine tension rather than as a convenience feature. The value of a rotating pool is that the address changes; the requirement of any multi-step task is that it does not. Without stickiness you would need a second product and a second integration for every job that involves a login. With it, one pool answers both, and the choice becomes a parameter instead of an architecture.
The duration is the entire design decision, and it cuts both ways. Too short and the address changes mid-flow, which typically presents as being logged out or bounced back to step one rather than as a clean error. Too long and you have quietly converted a rotating address into a static one, accumulating all of that session's history on a single IP and losing the spread that made the pool worth having.
The right length is therefore the length of the task and not a minute more. A login and a handful of authenticated calls might need two minutes. Working an account through a long sequence might need an hour. Holding an address for a day because the maximum allowed it is how people end up surprised that one IP now carries everything they did.
One thing it does not give you is a guarantee against the address disappearing. On residential pools the exit is a real household connection, and a household that goes offline ends the session regardless of the window you asked for. Code that assumes the address survives the full duration will eventually be wrong, so treat the window as an intent rather than a contract.
How it works
- 1.Decide how long the task genuinely needs the same exit address.
- 2.Request credentials with a sticky length in minutes; on our API that is the stickyMinutes field.
- 3.Omit that field entirely when you want ordinary per-request rotation instead.
- 4.Use the returned credentials for the whole flow, since the session is tied to them rather than to your connection.
- 5.Expect the ceiling to be finite. Ours holds an address for up to 24 hours, and a residential exit can still drop earlier if the underlying connection does.
Frequently asked questions
How long should a sticky session last?
As long as the task and no longer. A login plus a handful of authenticated calls might need two minutes; working an account through a long sequence might need an hour. Holding an address for a day because the maximum permitted it quietly converts a rotating address into a static one, with everything you did accumulating on a single IP.
Is a sticky session guaranteed to keep the same IP?
No, and code that assumes it will eventually be wrong. On residential supply the exit is somebody's home connection, and it can end at any moment regardless of the window you asked for. Treat the duration as an intent rather than a contract, and handle a changed exit as an expected event.
How do I request a sticky session?
Usually through the credentials rather than a separate endpoint. On our API it is the stickyMinutes field: set it to the length you need, or omit it entirely for ordinary per-request rotation. The session is tied to the credentials returned, so use those for the whole flow.
Sticky session or ISP proxy, which should I use?
It depends on how long persistence is needed. A sticky session is right for minutes or hours within a task and lets you keep using a rotating pool. An ISP proxy is right when one address must persist for weeks, because it is a datacenter machine rather than a borrowed household connection and does not disappear when somebody unplugs a router.
Back to the full glossary.