Which gateway should a Ticketmaster UK bot use?

The one nearest the machine running the bot, not the one nearest the site. A bot in Europe uses eu-residential2.basilproxies.com, a bot in the US uses us-residential2.basilproxies.com. The exit country comes from the -cc-gb token on the username, so both exit in the UK.

Should I add a London city token to a UK ticket string?

Only when you have a reason to need London specifically. -city-london narrows the pool to one city, and when that city has no free exit at that moment the gateway answers E20 and never falls back to the wider UK. -cc-gb on its own draws from the whole country.

What ttl should a UK ticket task use?

A little longer than the task, never longer than you need. -ttl- takes 1 to 1440 minutes and needs a -sess- token next to it. A sticky string with no ttl lasts 15 minutes, which is shorter than most ticket tasks.

Where do the tokens go, the username or the password?

The username, always. The password carries nothing and never changes. A token written on the password makes a pair the gateway has never seen, and every request comes back E01 invalid proxy login.

Ticketmaster UK on-sale: the proxy setup I'd run, token by token

2026-10-28 · Bazyl

This is the string I'd build for a Ticketmaster UK sale, one token at a time, with the reason for each and a check at the end that runs as written. The mistake I see most is copying a string that worked on some other store and changing nothing but the country. Every token is a decision, and two of them are decisions people make by accident.

The finished line looks like this. The rest of the post takes it apart.

eu-residential2.basilproxies.com:2115:USER-cc-gb-sess-tmuk01a7-ttl-90:PASS

The gateway: nearest the bot, not nearest the site

The first hop is chosen by where your machine sits. Three gateways serve one pool: eu-residential2.basilproxies.com, us-residential2.basilproxies.com and ap-residential2.basilproxies.com. The gateway decides the latency between your bot and us. It does not decide where the request exits.

On 1 October 2026 I measured the TCP connect time from a server in Falkenstein, Germany, five samples per gateway: eu- 7 to 21 ms, us- 113 to 148 ms, ap- 167 to 200 ms.

A bot in London or Frankfurt goes through eu. A bot on a US server running a UK sale goes through us and still exits in Britain, because of the next token.

-cc-gb: the country, and the only token you can't skip

Ticketmaster UK lives on ticketmaster.co.uk, prices in pounds, and the exit you want is a British home connection. -cc-gb asks for exactly that: an ISO two-letter code, case doesn't matter. Leave it off and the string exits anywhere in the world.

Note the code is gb, not uk. An unknown value is an error, not a guess, and the gateway answers it with one of the E10 to E15 lines that mean a malformed username. Nothing is silently ignored, which is the point: a typo costs you a refused test, not a sale run from the wrong country.

-city-london: worth it only with a reason

-city-london narrows the exit to London. It needs cc beside it and can't be combined with -isp-. The code comes from the dashboard's city picker, lowercase with spaces removed. On 1 October 2026 the picker listed 1,254 cities for the UK.

The cost is supply. Targeting never falls back to a wider area: when London has no free exit at that moment, the gateway answers E20 no exit for this targeting, change it or retry instead of handing you Manchester. Across a whole country that almost never comes up. On one city at the moment a big sale opens, it can.

My rule: country only, unless something about the sale ties it to a place and you've tested the city string the day before. "London feels safer" is not a reason. The same goes for -isp- with an ASN: precise, narrower, and an E20 when it can't fill.

-sess-: one id per task, never one per bot

A session token makes the line sticky. The same id keeps the same exit, so a task that started on one address finishes on it. The id is up to 32 lowercase letters or digits, and you pick it.

Every task gets its own id. Say a bot runs 12 tasks on this sale (an example, not a recommendation): that's 12 lines, tmuk01a7 to tmuk12a7 or 12 random ids, not one line pasted 12 times. Two tasks on one id share one exit and look like one visitor. The dashboard generator writes up to 100,000 lines per generation, each with its own id, so there's no reason to share.

Leave the session token off and every request gets a new IP. That's right for a page monitor that only reads and wrong for anything that holds a place. The sticky vs rotating post goes through that split task by task.

-ttl-: longer than the task, and written out

-ttl- is the session's lifetime in minutes, 1 to 1440, and it needs sess. Here's the accident: a sticky line without ttl lasts 15 minutes. Most ticket tasks run longer than that, and a task whose exit changes partway is a new visitor halfway through.

Size it to the task with margin. If you expect a task to take an hour, -ttl-90 covers it. Don't reach for 1440 by habit; a session still alive a day later isn't helping anything.

One more timer runs underneath: an idle tunnel closes after about 60 seconds of silence. The session survives that, because the id is what holds the exit, so a bot that reconnects with the same string gets the same address back while the ttl lasts.

The password: nothing goes there

The full form is http://USER-<tokens>:PASS@<gateway>:2115. Your login starts basl_ and the password never changes. Every token rides the username in any order, each key once, and our builders write them as cc, then city or isp, then os, then sess, then ttl.

Put -cc-gb on the password and the pair matches nothing. Every request answers E01 invalid proxy login. If your bot's config has separate user and password fields, the tokens go in the user field. A login that starts with res2_ predates 27 October 2026 and keeps the legacy format; the docs show it.

The check: authenticate, stick, exit in GB

Run this the evening before and again a few minutes before the sale. A brand-new login can answer 407 or E53 login not ready yet for its first minute or two while it reaches every gateway, and you want that minute behind you.

PROXY="http://USER-cc-gb-sess-tmuk01a7-ttl-90:[email protected]:2115"

A=$(curl -s --max-time 20 -x "$PROXY" https://api.ipify.org)
B=$(curl -s --max-time 20 -x "$PROXY" https://api.ipify.org)
C=$(curl -s --max-time 20 -x "$PROXY" https://ipinfo.io/country)
echo "$A / $B / $C"
[ -n "$A" ] && [ "$A" = "$B" ] && [ "$C" = "GB" ] && echo OK || echo "check failed"

Same IP twice and GB means the line is sticky and British. A different second IP means a new session id. Port 2115 is an HTTP proxy and https:// targets tunnel through it; there is no SOCKS5 on this pool, so don't set the task to it.

Budget and price, on made-up numbers

I don't publish how much data a sale uses. Run your first one on a small pay-as-you-go balance, which starts at 1 GB and never expires, and read the dashboard's statistics page the morning after: its per-domain table shows what ticketmaster.co.uk cost you.

As of 25 September 2026 in US dollars: 1 GB $4.20, 5 to 14 GB $3.60, 15 to 29 GB $3.00.

The pricing page shows the same ladder in pounds when you open it from the UK. Set /alerts with the Basil bot on Discord so a low balance DMs you before it stops the tasks: at zero, the gateway refuses every connection until you top up.

We answer for the proxy being live and reachable from Britain; what Ticketmaster does with the request is Ticketmaster's. The strings and the rest of the setup are on the ticket drops page.

Common questions

Which gateway should a Ticketmaster UK bot use?: The one nearest the machine running the bot, not the one nearest the site. A bot in Europe uses eu-residential2.basilproxies.com, a bot in the US uses us-residential2.basilproxies.com. The exit country comes from the -cc-gb token on the username, so both exit in the UK.
Should I add a London city token to a UK ticket string?: Only when you have a reason to need London specifically. -city-london narrows the pool to one city, and when that city has no free exit at that moment the gateway answers E20 and never falls back to the wider UK. -cc-gb on its own draws from the whole country.
What ttl should a UK ticket task use?: A little longer than the task, never longer than you need. -ttl- takes 1 to 1440 minutes and needs a -sess- token next to it. A sticky string with no ttl lasts 15 minutes, which is shorter than most ticket tasks.
Where do the tokens go, the username or the password?: The username, always. The password carries nothing and never changes. A token written on the password makes a pair the gateway has never seen, and every request comes back E01 invalid proxy login.