Getting started

Rotating vs sticky sessions, and location targeting

How the _sticky and _loc_<CODE> suffixes work, how to combine them, and the US location codes available today.

Every credential can run in either session mode, and you choose per request , not per account, by appending a suffix to the username. The full grammar:

<username>[_loc_<CODE>][_sticky]

Location comes before the mode suffix when you combine them.

Rotating: the default

Send a request with your credential's username as-is, no suffix, and you get a fresh exit IP on every request:

mlabs_a1f9c3:<PASSWORD>@proxy.masklabs.io:8080

Two requests through that login can land on two different exit IPs. This is the right default for bulk fetches across many targets, or high volume against one target where you don't want to hammer a single exit.

Sticky: pin one IP for about 60 seconds

Append _sticky:

mlabs_a1f9c3_sticky:<PASSWORD>@proxy.masklabs.io:8080

Same credential, same password, just a suffix at connect time. Reach for sticky when the target needs continuity across requests: a login flow, a multi-step checkout, or a paginated search that keys results to the requesting IP.

Location targeting: _loc_<CODE>

Append _loc_<CODE> to restrict exits to one US location:

mlabs_a1f9c3_loc_ORD:<PASSWORD>@proxy.masklabs.io:8080

Combine it with _sticky, location first, then the mode suffix:

mlabs_a1f9c3_loc_ORD_sticky:<PASSWORD>@proxy.masklabs.io:8080

Location codes

These are the codes we maintain display labels for today:

CodeCity
ATLAtlanta, GA
ABQAlbuquerque, NM
BWIBaltimore, MD
BHMBirmingham, AL
BILBillings, MT
BOSBoston, MA
BUFBuffalo, NY
CLTCharlotte, NC
ORDChicago, IL
CMHColumbus, OH
DFWDallas-Fort Worth, TX
DENDenver, CO
DSMDes Moines, IA
DTWDetroit, MI
BDLHartford, CT
HOUHouston, TX
HSVHuntsville, AL
INDIndianapolis, IN
JAXJacksonville, FL
JANJackson, MS
HNLHonolulu, HI
IDAIdaho Falls, ID
MCIKansas City, KS
LASLas Vegas, NV
LITLittlerock, AR
LAXLos Angeles County, CA
MIAMiami, FL
MKEMilwaukee, WI
MSPMinneapolis, MN
NYCNew York, NY
EWRNewark, NJ
ORFNorfolk, VA
OMAOmaha, NE
PHLPhiladelphia, PA
PHXPhoenix, AZ
PWMPortland, ME
PDXPortland, OR
RICRichmond, VA
SLCSalt Lake City, UT
SATSan Antonio, TX
SANSan Diego, CA
SJCSan Jose, CA
SEASeattle, WA
SHVShreveport, LA
STLSt. Louis, MO

These codes are what we maintain city labels for; they aren't a live availability guarantee. A location is only offered when at least one upstream is actually up in it, so the definitive list is whatever the dashboard's endpoint builder shows you at the moment you build a connection string, check there before hardcoding a code into a long-running job. Requesting a code that isn't currently serviceable fails the connection rather than silently falling back to another location.

Mixing modes from one pool

Because the mode and location are per-request suffixes, not account settings, different credentials on the same organization can run different combinations simultaneously, a crawler credential doing high-volume rotating fetches, and a checkout-flow credential running sticky and location-pinned for the handful of requests that need it. Both draw from the same shared GB balance, each with its own usage line in the dashboard.