Reseller
Automating Sub-User Provisioning With the GlobProxy Reseller API
·2 min read
Manually creating a sub-user in the dashboard for each new client works fine at small scale. It stops working the moment onboarding needs to happen without you personally clicking through a form — a self-serve signup flow on your own site, a batch of clients onboarded at once, or any workflow where sub-user creation needs to be a side effect of something else happening in your own system. That's what the reseller API is for.
The core loop
- 1Create a sub-user with an initial GB allocation via `POST /api/v1/sub-users`
- 2Store the returned credentials against your own client record
- 3Track usage via `GET /api/v1/sub-users/:id/usage` — synced live from the upstream network while the credential is active
- 4Top up via `POST /api/v1/sub-users/:id/topup` when a client needs more, or turn on `PATCH /api/v1/sub-users/:id/auto-topup` so it happens without you in the loop at all
- 5Delete via `DELETE /api/v1/sub-users/:id` when a client churns — this releases whatever portion of the reservation was never used back to your available stock
A minimal creation call
This is the same request the docs show — worth including here because it's genuinely the whole shape of it:
curl -X POST https://globproxy.com/api/v1/sub-users -H "Authorization: Bearer YOUR_API_KEY" -d '{"gb_allocated": 5}'— GlobProxy API docs — Create sub-user
What to actually build around this
- →A webhook or polling check on your side that reacts to a client hitting their allocation limit — the API tells you usage, but what you do when it's nearly exhausted is your own logic
- →A mapping table between your own client IDs and GlobProxy sub-user IDs — the API doesn't know your client system, so this join lives entirely on your side
- →Error handling for the specific status codes the docs call out — a 402 means your own stock is insufficient for the request, a 409 on whitelist endpoints means the sub-user is still provisioning, not a real conflict
- →A deletion hook tied to your own client-churn event, so released bandwidth actually flows back to your available stock instead of sitting allocated to a dead account
Full reference
This post covers the shape of it — the complete endpoint reference with every parameter and response field lives in the API docs.
Frequently asked
Is there a limit to how many sub-users I can create?
The practical limit is your available bandwidth stock, not a hard cap on sub-user count — each creation call reserves GB from your account balance.
What happens to a sub-user's unused bandwidth if I delete it?
Whatever portion of the reservation was never used is released back to your own available stock.
Try it on 1 GB before you commit to more.
Non-expiring bandwidth, 195 countries, city-level targeting — from $4.50.
Get started →