Once more than one person or project uses a proxy account, the same questions arrive. How do we stop the whole team sharing one credential. How do we tell which client consumed which gigabytes. How do we cut off a contractor’s access without breaking everyone else. In this industry those questions usually get answered with the phrase “sub-users”, and the phrase means different things depending on who is selling.
Here is what sub-users actually are, what the residential product does and does not provide, and how to solve the three underlying problems either way.
What sub-users mean in this market
A sub-user, where a provider offers one, is a secondary set of proxy credentials issued under a parent account. Typically it can carry its own bandwidth cap, sometimes its own targeting restrictions, and it can be revoked without touching the parent. It is an access-control feature attached to the traffic itself.
Teams want them for three distinct reasons, and it is worth separating those, because they have different solutions.
Isolation. Different people or projects should not share one credential, so that a leak or a departure has a contained blast radius.
Attribution. Someone needs to know which client, team, or project used which portion of the bandwidth, usually for billing or margin.
Limits. One project should not be able to consume the whole plan, either by accident or through a runaway job.
What the residential product provides
Being direct about it: Shifter’s residential proxies do not have per-sub-user proxy credentials. Authentication is one username and password, with targeting and session options expressed inside the username, as documented in gateway and authentication. There is no facility to mint a second proxy credential with its own bandwidth cap.
What does exist splits across two mechanisms, and between them they cover the three problems above.
Team Workspaces handle access to the account. You invite people by email and assign a role: Viewer for read-only visibility into memberships, traffic and invoices, Billing for those plus funding and purchasing, and Admin for full membership and team management. Roles are scoped per workspace rather than globally, removal is immediate and kills existing sessions, and one person can belong to several workspaces and switch between them with one login. The full behaviour is in the Team Workspaces announcement.
Session identifiers handle segmentation of the traffic. Every request can carry a session ID of your choosing, which is what makes per-client and per-project attribution possible without separate credentials.
The distinction to hold onto: workspaces control who can administer the account, session identifiers organise what the traffic is doing. Sub-users, where they exist elsewhere, blur those together.
Solving isolation without sub-users
Since one credential serves everything, the isolation work moves to how you store and expose it.
Keep the credential in a secret manager rather than in code, configuration, or a shared document, and let applications read it from the environment at runtime. People do not need the proxy credential to do their jobs; the systems do. An engineer who needs to test can be given access to a service that uses it rather than the value itself.
Where you genuinely need separate blast radii, separate workspaces with their own plans give you genuinely separate credentials, since plans do not cross workspaces. That is heavier than a sub-user and it means separate billing, so it fits the case where a client or business unit should own its own account anyway rather than the case where you just want tidiness.
Then plan for rotation before you need it. Because one credential is shared, rotating it affects everything at once, so treat it as a deployment: update the secret store, roll every client, then invalidate the old value. Skipping that order is the most common way a team discovers how many places the credential lives, as every one of them starts returning 407 errors simultaneously.
For people rather than systems, offboarding runs through workspace roles: remove the member and their panel access ends immediately, including any open session. That covers the contractor case, which is usually what is really being asked.
Solving attribution without sub-users
This is where session identifiers do the work, and it is worth structuring them deliberately from the start.
Encode the tenant in the session ID so every request is traceable to whoever it was for. The ID is any string you choose, so a structured convention costs nothing and makes attribution a matter of parsing your own logs:
def proxy_for(client, job, country, ttl=600):
sid = f"{client}-{job}" # e.g. acme-prices-0827
user = f"customer-USERNAME-country-{country}-sid-{sid}-ttl-{ttl}"
url = f"http://{user}:PASSWORD@p.shifter.io:443"
return {"http": url, "https": url}Then record bytes per request against the client, because the provider’s invoice is a single total for the account and cannot tell you the split. Summing response sizes per tenant gives you a usage figure to bill against or to compute margin from, and reconciling your total against the invoice periodically keeps it honest, since retries, failed requests and connection overhead all consume bandwidth a naive body-size count misses. The metric to watch per tenant is bytes per record, which is covered in proxy KPIs and is the number that turns attribution into a cost conversation.
Sessions also serve their original purpose here: distinct identifiers per client prevent two clients’ flows from colliding on the same session, which matters as soon as more than one job runs at a time. The semantics are in sticky versus rotating.
Solving limits without sub-users
There is no provider-side cap per tenant, so the cap has to live in your own scheduler, and honestly that is where it belongs anyway: your system knows what a client is entitled to, the proxy does not.
Give each tenant a bandwidth budget for the period and enforce it against the usage you are already recording, stopping or queueing that tenant’s jobs when it is exhausted rather than letting it eat the shared allocation. Alert well before the limit rather than at it. Pair that with per-tenant concurrency shares so one large overnight batch cannot starve four small time-sensitive jobs, and with per-tenant retry budgets so one client’s failing target cannot flood the shared pool, which is the containment argument in retry and backoff and rate limiting.
The natural home for all of this is the component that already sees every request, which is why a proxy manager is the right place to put tenant budgets, concurrency shares and attribution rather than scattering them across jobs.
Choosing between one account and many workspaces
The decision is usually simpler than it looks, and it comes down to who owns the commercial relationship.
Run one account with logical tenants when you are delivering a service and the vendor is your supply chain: you buy the bandwidth, clients never see the provider, and segmentation is a naming convention in your own code. This is the common agency shape.
Run a workspace per client when the client should own its own plan and invoices, with your team added as Admins. Billing is genuinely separate, traffic cannot be co-mingled because plans do not cross workspaces, and the client can take over cleanly if the engagement ends.
Designing around a tenant identifier from day one is what makes moving between those a configuration change rather than a rebuild.
The bottom line
Sub-users are one implementation of three separate needs, and they are not the only implementation. On the residential product there is one proxy credential, so isolation comes from secret management and, where it must be absolute, from separate workspaces with their own plans; access control for people comes from workspace roles with immediate revocation; attribution comes from structured session identifiers plus your own per-tenant byte accounting, because the invoice is a single total; and limits come from budgets in your scheduler, which is the only place that knows what each tenant is entitled to. If you build around a tenant identifier from the start, you get all three, and you keep the option of moving a client onto their own workspace later without touching the collection code.
The layer underneath is residential proxies: one gateway where country, city, session and TTL are all expressed per request, which is exactly what makes per-tenant segmentation a naming convention rather than a product limitation, with per-GB pricing so the usage you attribute internally is measured in the same unit you are billed in.