Argos and Hamleys: UK toy restocks on British exits

2026-10-30 · Bazyl

After this post you can set up one bot to watch and check out on Argos and Hamleys on British residential exits, with the monitor and the checkout kept apart. The mistake I see most is running both jobs on the same string: either the monitor parks all its requests on one address, or the checkout changes address between the basket and the payment page.

Both stores are British. Argos is at argos.co.uk, Hamleys at hamleys.com, both sell in pounds sterling, both in English. That makes the targeting the easy part. The work is in how you split the tasks.

One country token covers both stores

Every line for either store carries -cc-gb. That's the exit country, as an ISO two-letter code, and it rides the username like every other token. The gateway doesn't decide the country. The token does.

So the gateway choice is about where your bot runs, not where the stores are. A bot on a server in Germany or the Netherlands uses eu-residential2.basilproxies.com. A bot on a machine in the US uses us- and still exits in Britain, because the token says so. From a server in Falkenstein on 1 October 2026 we measured 7 to 21 ms to the eu- gateway and 113 to 148 ms to us-.

For a UK toy store, then, eu with -cc-gb is the default for anyone running in Europe.

The monitor rotates, the checkout sticks

A monitor wants a new address on every request. A checkout wants one address from the basket to the confirmation page. Those are two different strings, and the difference is one token.

A line with no -sess- token rotates. Add -sess- with an id of your own and it becomes sticky: the same id keeps the same exit until its -ttl- runs out. Without -ttl- a sticky line lasts 15 minutes; with it, anything from 1 to 1440 minutes.

For a toy restock checkout, 30 minutes is plenty. The point is to cover the checkout with margin, not to hold an address all day.

# Monitor, both stores: new British IP on every request
eu-residential2.basilproxies.com:2115:USER-cc-gb:PASS

# Checkout task 1 on Argos: one British IP for 30 minutes
eu-residential2.basilproxies.com:2115:USER-cc-gb-sess-arg01k4m-ttl-30:PASS

# Checkout task 1 on Hamleys: its own session id, its own IP
eu-residential2.basilproxies.com:2115:USER-cc-gb-sess-ham01x9d-ttl-30:PASS

A login that starts with res2_ predates 27 October 2026 and keeps the legacy format: the docs show it.

Give each store its own session ids

Two stores means two sets of tasks, and no task shares an id with another. I prefix the ids by store, arg and ham, so a line in the bot's log tells me at a glance which store it belongs to. The gateway doesn't care about the prefix. Ids are up to 32 lowercase letters or digits.

Here is a short script that writes ten Argos and ten Hamleys checkout lines with random ids, ready to paste into a bot that takes host:port:user:pass:

#!/usr/bin/env bash
# uk-toys.sh: one sticky British line per checkout task, per store.
LOGIN="USER"     # your basl_ login, e.g. basl_7k2m9x4z
PASS="PASS"
GW="eu-residential2.basilproxies.com:2115"

for store in arg ham; do
  for i in $(seq 1 10); do
    id="${store}$(openssl rand -hex 4)"
    echo "${GW}:${LOGIN}-cc-gb-sess-${id}-ttl-30:${PASS}"
  done > "${store}-checkout.txt"
done
wc -l arg-checkout.txt ham-checkout.txt

openssl rand -hex 4 gives eight lowercase hex characters, which is a valid session id on its own. The dashboard generator does the same job for up to 100,000 lines at a time if you'd rather click than script.

Leave the city token off unless you need it

-city-london is a real token, and London is a code in the dashboard's picker. On 1 October 2026 the picker listed 1,254 cities for the UK. That's tempting.

But a city token narrows the pool to that city, and when that city has no free exit at the moment you ask, the gateway answers E20 no exit for this targeting, change it or retry. It never falls back to the rest of the country. For a store that sells to the whole of Britain, country targeting gives you the widest supply and loses nothing.

If a task does get E20, the fix is in the string: drop the city, or retry later. Not a new password.

Read the two stores apart on the statistics page

The dashboard's statistics page has a per-domain table of your top targets, next to bandwidth and request charts from 24 hours to 30 days, a success rate and latency. Argos and Hamleys are different domains, so they show as different rows. After a restock you can see which store your gigabytes went to without guessing.

For a cleaner split, put each store on its own sub-account. You get up to five, each with its own credentials and balance, and the statistics page follows the account you select. A sub-account can refill itself from Main when it drops below 1 GB, so neither store runs dry while the other still has data.

What it costs to start

Pay as you go starts at 1 GB and never expires, so a first restock can be a test. As of 1 October 2026, in US dollars: 1 GB is $4.20, 5 to 14 GB $3.60 a gigabyte, 15 to 29 GB $3.00.

Prices are charged in GBP too, if you pick it at checkout; the pricing page shows the ladder in your currency.

Run one restock, read the per-domain rows, and size the next purchase from them.

What we answer for

We don't promise a checkout on Argos, Hamleys or any other store. We answer for the proxy being live and reachable from the country you asked for, here Britain. What a store does with a request is the store's.

If a line connects and the store still refuses it, that exit is spent for that store: rotate the session id, and check the statistics page to see whether the refusals cover the whole domain or one task.

For the rest of the retail setup, the sneakers and retail page has the strings and the session model in one place.