How to Manage Proxy Sub-Users and Rotate Credentials

Most buyers do not need every feature a vendor lists on its account-management page. Find your row, then ask only for what it names.

The most common overspend in this category is buying a higher tier for "team features" when the real requirement was three credential pairs and a naming convention. The most common underspend is running an entire company off one shared login because the plan never offered anything else, then discovering at rotation time that eleven services hold the same secret.

Three things get conflated in vendor marketing. Separating them tells you what a sub-user can and cannot do for you.

Read the middle row twice, because it is the assumption that burns teams. Creating ten sub-users does not multiply your concurrency. On a plan sold with 250 threads, ten sub-users share those 250 threads unless the provider lets you cap each one. If your reason for wanting sub-users is more capacity, you need a bigger plan, not more usernames. Our explainer on concurrent connections in proxies covers how that pool is metered.

What a sub-user does give you is four things that matter: blast radius, attribution, revocation, and least privilege. Each credential can be switched off on its own, each one shows up separately in usage reporting, each one can be scoped to the proxy types a job legitimately needs, and a leaked one costs you a single job instead of the whole estate. The mechanics of the credential itself are unchanged. It is the same username:password pair sent in the same Proxy-Authorization header, as covered in how proxy authentication works.

Send these to sales, in writing, before the card goes in. The answers separate providers far more sharply than pool-size claims do.

Question 6 is the one people skip and later regret. Ask for the number in seconds, then verify it during the trial: revoke a test credential, then hammer the gateway until it returns 407. If the vendor cannot state the number, assume it is slow.

A credential should be the smallest unit you would be willing to switch off without asking permission. That gives you a formula rather than a guess:

credentials = (jobs x environments) + humans doing manual work + 1 break-glass

Worked example for a mid-size price monitoring team: 6 scraping jobs, two environments (production and staging), 2 analysts running ad-hoc pulls, and one break-glass pair kept in the password manager and never deployed. That is (6 x 2) + 2 + 1 = 15 credentials.

Fifteen credentials sounds like a lot until the first incident, when the difference between pausing one credential and pausing the company is the entire point of the exercise. This count is independent of thread count. Sizing threads is a separate calculation driven by request rate and target latency, worked through in our guide to rotating proxies and per-IP request limits.

Random usernames are how a credential ends up orphaned: still active, still billing, and nobody willing to delete it because nobody knows what breaks. Fix that with a naming scheme and a registry file.

Scheme: team-job-env-seq, lowercase, no personal names.

pricing-amazon-prod-01
pricing-amazon-stage-01
seo-serp-prod-01
seo-serp-prod-02
ops-breakglass-01

Then keep an inventory in the repo that owns the scrapers. It holds no secrets, only metadata, so it is safe to commit:

# credentials.yml  (metadata only, never the password)
- user: pricing-amazon-prod-01
  owner: data-platform
  purpose: hourly ASIN price pull
  gateway: gateway.sparkproxy.io:11000
  created: 2026-07-14
  rotate_by: 2026-10-14
  secret_ref: vault://proxy/pricing-amazon-prod-01
- user: seo-serp-prod-01
  owner: growth
  purpose: daily rank tracking
  gateway: gateway.sparkproxy.io:11002
  created: 2026-08-02
  rotate_by: 2026-11-02
  secret_ref: vault://proxy/seo-serp-prod-01

The rotate_by field is what turns rotation into a scheduled task instead of a fire drill. A weekly CI check that fails the build when any date falls inside the next 14 days takes an hour to write and removes the whole class of "we forgot" incidents. If you already run scheduled jobs, bolt it onto the same scheduler that runs the scrapers, as described in how to schedule and automate web scrapers.

The reason most teams never rotate is that they picture a hard swap: change the password, restart everything, hope. Do it as an overlap instead. Two credentials are valid at the same time, traffic moves, then the old one dies.

Step 2, the smoke test, is one command:

curl -s -x "http://pricing-amazon-prod-02:NEWPASS@gateway.sparkproxy.io:11000" \
     https://api.ipify.org
# prints an egress IP if the credential works
# returns 407 Proxy Authentication Required if it does not

Step 4 is what buys the zero downtime. Workers load both credentials and fall back on an auth failure, so an early revocation or a typo degrades instead of breaking:

import os, requests

GATEWAY = "gateway.sparkproxy.io:11000"

CREDS = [c for c in (os.environ.get("PROXY_PRIMARY"),
                     os.environ.get("PROXY_SECONDARY")) if c]

def fetch(url, timeout=30):
    last = None
    for cred in CREDS:
        proxy = f"http://{cred}@{GATEWAY}"
        try:
            r = requests.get(url, proxies={"http": proxy, "https": proxy},
                             timeout=timeout)
        except requests.RequestException as exc:
            last = exc
            continue
        if r.status_code == 407:          # dead credential, try the next one
            last = r
            continue
        return r
    raise RuntimeError(f"all proxy credentials failed: {last}")

PROXY_PRIMARY and PROXY_SECONDARY hold user:password strings injected from the secrets manager, never from the repo. The same two-credential pattern slots into whatever rotation layer you already run, including the pool logic in how to rotate proxies in Python.

Step 7 deserves its own emphasis. A rotation that never revokes the old credential is not a rotation, it is credential accumulation. Confirm the revocation, and expect a 407 rather than a timeout. If your provider returns something else, check it against our reference on proxy error codes so your monitoring classifies it correctly.

Sensible cadence: every 90 days for production jobs, immediately on any team departure, and immediately on any suspected exposure. Quarterly is frequent enough to keep the runbook warm and rare enough that nobody starts skipping it.

Credentials are usually cheap and plentiful. Whitelisted IPs are not, because every provider caps them by plan. Here is how that budget looks on SparkProxy's published datacenter plans, all with unlimited bandwidth and 30 days of validity:

Higher tiers exist for larger concurrency requirements, Pro at 1500 threads and Pro+ at 2000, and those are quoted rather than list priced. Fair usage speed caps run 25, 50, 100, 150, 200, and 250 Mbps up that ladder, with custom arrangements to 1 Gbps. Treat those figures as ceilings, not promised throughput.

Budget the slots deliberately. Put your workers behind a single fixed egress, a NAT gateway or a bastion, and one slot covers an entire cluster. Burn a slot per developer laptop and a five-slot plan is gone before production starts. Ephemeral CI runners are the classic trap, since their public IP changes per run, which makes them a job for username-password auth rather than whitelisting. The trade-offs in both directions are laid out in what IP whitelisting is for proxies.

Gateway details, for the smoke test above: gateway.sparkproxy.io, port 11000 for HTTP and HTTPS, port 11002 for sticky sessions, port 13000 for SOCKS5. If a job needs the same exit IP across a multi-step flow, it belongs on the sticky port, and it wants its own credential so you can reason about it separately. See what a sticky session proxy is for when that applies.

If you buy a scraping API instead of raw proxies, the credential is an API key and every rule above still applies, with one addition: keys usually carry a spend limit. A leaked proxy password costs you bandwidth. A leaked API key costs you credits, and credits have a price list.

For reference, SparkProxy's Scraping API bills 1 credit for a plain fetch, 5 for a JavaScript render, and 10 for a screenshot or PDF. Plans run Starter $49 for 250,000 credits and 50 concurrent requests, Growth $99 for 1,000,000 credits and 100 concurrent, Pro $249 for 3,000,000 and 200 concurrent, and Scale $599 for 8,000,000 and 400 concurrent. There are 1,000 free credits with no card, which is enough to rehearse a rotation drill end to end before committing to anything.

Three rules for keys specifically. Give every environment its own key, so a staging leak never touches production credits. Never ship a key to anything a user can open, including browser extensions and mobile apps, because a key in client code is public the moment it ships. And alert on credit burn rate rather than monthly totals, since a stolen key looks exactly like a busy afternoon until the month closes.

Revoke first. Investigate second. The instinct to work out what happened before touching anything is how a 20 minute incident becomes a weekend.

Proxy credentials leak through boring routes. A hardcoded string in a scraper committed before anyone set up a secrets manager. A Dockerfile ENV line baked into a published image. A CI log that prints the full proxy URL in a debug line. A support ticket screenshot with the password visible in a config panel. Scan for the gateway hostname across your repos and image layers, because a grep for gateway.sparkproxy.io finds every embedded URL in one pass.

Detection is where per-user reporting earns its keep. Unexplained thread saturation on one credential, traffic during hours that job never runs, or requests to targets that job never touches are all visible when usage is attributed per sub-user, and invisible when it is not. That is question 4 on the buying checklist, and it is why the question is on the list. If you also expose proxy access to internal services, the abuse patterns in securing proxy servers against SSRF and proxy abuse are worth reading alongside this.

One credential for everything. The cheapest mistake to avoid and the most expensive to unwind. When it leaks, every job stops at once, and the rotation touches every service you own.

Buying more sub-users to get more throughput. Sub-users partition identity, not capacity. If jobs are queueing, the fix is threads.

Calendar rotation with no revocation test. Teams that rotate quarterly but never verify the old pair is dead usually have a trail of live orphans behind them. Test for the 407.

Whitelisting an office range. A /24 on the allowlist means every device on that network, guests included, can use your plan. Whitelist single addresses you control.

Rotating without a fallback. A hard swap with no secondary credential turns a typo into a full outage. The two-credential pattern above removes that failure mode for the price of one environment variable.

No owner recorded. A credential with no named owning team is a credential nobody will ever dare delete. Put the owner in the registry on day one.