Jul 5, 2026 · 5 min read
Sticky vs Rotating Sessions: When to Use Each for Sneaker Bots
The rotating-vs-sticky decision is where most beginners lose the drop. Sneaker sites have wildly different expectations of what a "session" looks like, and getting it wrong triggers a specific detection pattern each site is tuned for.
Cheat sheet first, then the reasoning.
The cheat sheet
- Nike SNKRS: Sticky 10–30 min
- Shopify (Supreme / Palace / Kith / Bape): Sticky 15–30 min
- Yeezy Supply: Sticky 20–30 min (queue is long)
- Adidas Confirmed: Sticky 15 min
- Foot Locker / JD Sports: Sticky 5–10 min OK
- Sneakersnstuff / END / Notre: Sticky 10 min
- Monitoring / scraping (not checkout): Rotating fine
- Account creation / warming: Sticky 30 min per account, then release
If you can only remember one rule: for checkout, always sticky. For monitoring, rotating is fine.
Why sticky wins on checkout
Sneaker checkout flows are a chain of interdependent requests. A typical Nike checkout looks like:
- GET home page → session cookie set on IP-A
- GET PDP → session cookie validated against IP-A
- POST cart → cart validated against session cookie + IP-A
- POST checkout → checkout token validated against cart + IP-A
- POST payment → auth validated against checkout token + IP-A
If IP-A becomes IP-B at any point in that chain, the fraud engine sees an impossible geographic hop. Real customers don't teleport between IPs during a 3-minute checkout. Bots on rotating proxies do.
Sticky sessions hold the same IP for a configured duration (5, 10, 30 minutes). Long enough to finish checkout, short enough that when you release the session, someone else gets to use that IP for their traffic.
Why rotating wins on scraping
When you're scraping — hitting the same page 500 times to monitor inventory or gather product data — sticky IPs get rate-limited. The site sees the same IP hitting the same endpoint 500 times in an hour and blocks it.
Rotating proxies fix this by fanning your 500 requests across 500 different IPs. From the site's perspective, it looks like 500 different customers each looking at the product once. No rate limit trips because no IP crossed the threshold.
The middle ground: task-scoped sticky
What if you have 20 checkout tasks running in parallel on drop day? Answer: 20 sticky sessions with different session IDs.
SMT proxy format:
premium-residential.smtproxies.com:10000:USERNAME-country-us-session-TASK01-lifetime-30:PASSWORD
premium-residential.smtproxies.com:10000:USERNAME-country-us-session-TASK02-lifetime-30:PASSWORD
...
premium-residential.smtproxies.com:10000:USERNAME-country-us-session-TASK20-lifetime-30:PASSWORD
Each unique session-TASK## string gives you a different sticky IP. All 20 tasks run on independent 30-minute sticky sessions. Perfect for a big drop-day run.
Sticky lifetime — why 5 vs 30 min matters
Shorter stickies release IPs back to the pool faster. Good for:
- High-turnover tasks that finish quickly
- Sites with soft rate limits per IP-hour
Longer stickies hold IPs. Good for:
- Sites with multi-step checkout (Yeezy Supply queue can take 20+ minutes)
- Warm-up sequences that need to look like one continuous session
- Account creation flows (email → verify → login → settings → done)
Default to 30 minutes if you're not sure. Costs nothing extra on our pricing, gives you headroom.
Common mistakes
- Using rotating for checkout because "it looks more human." Real humans keep the same IP through checkout. Rotating stands out.
- Using sticky for high-volume scraping. The site sees 500 requests from one IP and rate-limits you.
- Same sticky session across accounts. Two accounts on the same IP = correlation = both banned.
- Sticky lifetime = 1 min. Too short. The IP flips mid-checkout. Use 10+ min for anything with a payment step.
How to think about it
Ask "does this workflow have state that persists across requests?"
- Yes → sticky (checkout, account actions, queues)
- No → rotating (monitoring, scraping, one-shot data collection)
That covers 95% of decisions.
Try SMT residential — 2 GB for $2. Both sticky and rotating included, configure per proxy string.