API Reference

Your account's overall bandwidth balance — not per sub-user, see the usage endpoint below for that. allocated_gb is what's already reserved into sub-users; available_gb is what you can still create or top up with.

curl https://globproxy.com/api/v1/account/bandwidth \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "total_gb": 500,
  "used_gb": 128.4,
  "allocated_gb": 210,
  "available_gb": 371.6,
  "expires": "never"
}

Who this key belongs to and what it may do — scopes, allowed IPs and expiry — so an integration can check itself (and warn before the key lapses) instead of guessing from 403s.

curl https://globproxy.com/api/v1/account \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "account": { "id": "9c1e...", "email": "you@example.com", "role": "reseller" },
  "api_key": { "id": "b72d...", "key_prefix": "gp_live_a1b2c3", "label": "billing-bot", "scopes": ["read", "write"],
               "allowed_ips": ["203.0.113.0/24"], "expires_at": "2027-01-10T00:00:00.000Z", "created_at": "2026-10-10T09:00:00.000Z" },
  "features": { "password_rotation": true }
}

features reports optional endpoints that are switched on per deployment — password_rotation: false (an operator kill switch; on by default) means rotate-password answers 503.

Account-wide data usage per UTC day for the last days days (1–365, default 30), oldest first, gaps filled with 0. Served from our own ledger, so it is cheap, includes deleted sub-users, and is not subject to the tighter /usage/history limit. The ledger is updated every few minutes; first_recorded_day is where it begins (earlier days read 0 because nothing was recorded).

curl "https://globproxy.com/api/v1/account/usage?days=7" \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "from": "2026-10-17", "to": "2026-10-23", "days": 7, "total_gb": 12.4081,
  "first_recorded_day": "2026-09-02",
  "usage": [ { "date": "2026-10-17", "gb": 1.2 }, { "date": "2026-10-18", "gb": 0 } ]
}

Every change (POST / PATCH / DELETE) made with your account's keys in the last 30 days — which key, from which IP, which path, the status and the X-Request-Id. Read-only requests are not logged. Query: key_id, limit (max 200), before (cursor).

curl "https://globproxy.com/api/v1/account/activity?limit=20" \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "activity": [
    { "id": 812, "key_id": "b72d...", "key_prefix": "gp_live_a1b2c3", "key_label": "billing-bot", "method": "POST",
      "path": "/api/v1/sub-users/3f1a.../topup", "status": 200, "ip": "203.0.113.7", "request_id": "5e0c...", "created_at": "2026-10-18T09:30:00.000Z" }
  ],
  "has_more": false, "next_before": null, "next_before_id": null
}

All proxy credentials (sub-users) on your account, newest first. Query parameters: limit, offset (see Pagination) and optional filters: status (pending, active or suspended), label (case-insensitive contains), country (2-letter code), session_type (rotating or sticky), protocol (http or socks5), created_after and created_before (ISO 8601).

curl https://globproxy.com/api/v1/sub-users \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "sub_users": [
    {
      "id": "3f1a...",
      "label": "Client A",
      "status": "active",
      "gb_allocated": 5,
      "gb_used": 1.2,
      "gb_remaining": 3.8,
      "country": "us",
      "state": "california",
      "city": null,
      "asn": null,
      "session_type": "rotating",
      "protocol": "http",
      "sticky_duration": null,
      "endpoint_count": 1,
      "host": "proxy.globproxy.com",
      "port": 9000,
      "username": "gp_1760000000000_ab12cd34",
      "password": "0b8f6c0e-...",
      "connection_username": "gp_1760000000000_ab12cd34-type-residential-country-us-state-california",
      "auto_topup": { "enabled": false, "threshold_gb": null, "amount_gb": null },
      "activated_at": "2026-08-01T12:00:00.000Z",
      "created_at": "2026-08-01T12:00:00.000Z"
    }
  ],
  "total": 1,
  "limit": 100,
  "offset": 0,
  "has_more": false
}

A working proxy connection is host:port with connection_username and password — use connection_username (not the raw username) because it has your targeting baked in. The password is the same one shown in your dashboard — treat API keys with the same care as the passwords they can read. For a sticky session, generate a fresh -session-* suffix per connection rather than reusing this one indefinitely; that logic lives client-side, this endpoint just returns the base credential.

Creates a new proxy credential and reserves the requested bandwidth from your account balance atomically — a burst of concurrent creates can't oversubscribe your balance. Supports Idempotency-Key (see above).

curl -X POST https://globproxy.com/api/v1/sub-users \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "Client A",
    "gb_allocated": 5,
    "country": "us",
    "state": "california",
    "protocol": "http",
    "session_type": "rotating"
  }'

Body parameters

Response — 201 Created

{
  "id": "3f1a...",
  "label": "Client A",
  "status": "active",
  "host": "proxy.globproxy.com",
  "port": 9000,
  "username": "gp_1760000000000_ab12cd34",
  "password": "0b8f6c0e-...",
  "connection_username": "gp_1760000000000_ab12cd34-type-residential-country-us-state-california",
  "gb_allocated": 5,
  "country": "us"
  // ...same fields as the list endpoint
}

status can come back "pending" instead of "active" if the upstream provisioning step is briefly unavailable — the credential and bandwidth reservation are still created and activation is retried automatically in the background (typically within a few minutes). While pending, username, password and connection_username are null, and pending_reason says why it isn't live yet: "capacity" (network capacity is being added), "unavailable" (a temporary outage) or "error". Subscribe to the session_activated webhook, or poll GET /api/v1/sub-users/:id, to know when it's live.

One sub-user, in the same shape as a list entry (including password and connection_username).

curl https://globproxy.com/api/v1/sub-users/SUB_USER_ID \
  -H "Authorization: Bearer YOUR_KEY"

Changes the label or connection settings. Targeting lives in the connection username, so this takes effect immediately and doesn't touch bandwidth (use /topup for that). Send only the fields you want to change; send null to clear a targeting field. Changing country also clears a state / city you don't send in the same request, since the old ones belong to the old country. Sub-users allocated by a reseller, and suspended ones, can't be edited (403).

curl -X PATCH https://globproxy.com/api/v1/sub-users/SUB_USER_ID \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "label": "Client A (EU)", "country": "de", "city": "berlin" }'

Body parameters

Returns the updated sub-user.

Current usage for a single sub-user, synced live from the upstream provider when the credential is active.

curl https://globproxy.com/api/v1/sub-users/SUB_USER_ID/usage \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "id": "3f1a...",
  "label": "Client A",
  "status": "active",
  "protocol": "http",
  "session_type": "rotating",
  "gb_allocated": 5,
  "gb_used": 1.2,
  "gb_remaining": 3.8,
  "country": "us",
  "state": "california",
  "city": null,
  "host": "proxy.globproxy.com",
  "port": 9000,
  "username": "gp_1760000000000_ab12cd34",
  "connection_username": "gp_1760000000000_ab12cd34-type-residential-country-us-state-california",
  "usage_synced_at": "2026-10-18T09:30:00.000Z"
}

Re-read from the provider at most every 30 seconds per sub-user; usage_synced_at says when the number was last refreshed.

A ready-made proxy list, built the same way as the dashboard's export. A sticky sub-user returns count stable endpoints (default: its endpoint_count, max 1000), each with its own session id so each keeps its IP for the sub-user's sticky duration. A rotating sub-user returns one endpoint — every connection to it already gets a fresh IP. format=txt returns plain text, one host:port:username:password line per endpoint. 409 while the sub-user is pending or suspended.

curl "https://globproxy.com/api/v1/sub-users/SUB_USER_ID/endpoints?count=3" \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "sub_user_id": "3f1a...", "protocol": "http", "session_type": "sticky", "rotating": false, "count": 3,
  "endpoints": [
    { "host": "proxy.globproxy.com", "port": 10000,
      "username": "gp_abc123-type-residential-country-us-lifetime-10-session-FVvegZQ7",
      "password": "…", "session_id": "FVvegZQ7",
      "url": "http://gp_abc123-type-residential-country-us-lifetime-10-session-FVvegZQ7:…@proxy.globproxy.com:10000" },
    { "host": "proxy.globproxy.com", "port": 10000,
      "username": "gp_abc123-type-residential-country-us-lifetime-10-session-bQ2V1sK3",
      "password": "…", "session_id": "bQ2V1sK3", "url": "…" }
  ]
}

Bandwidth and request counts over time for one sub-user. days is 1–90 (default 7); granularity is day (default) or hour (up to 30 days). 409 if the sub-user hasn't been activated yet.

curl "https://globproxy.com/api/v1/sub-users/SUB_USER_ID/usage/history?days=7&granularity=day" \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "id": "3f1a...",
  "from": "2026-10-11T09:30:00.000Z",
  "to": "2026-10-18T09:30:00.000Z",
  "granularity": "day",
  "total_gb": 1.2,
  "points": [
    { "period_start": "2026-10-11T00:00:00.000Z", "gb": 0.31, "successful_requests": 4120, "failed_requests": 37, "success_rate": 99.1 }
  ]
}

Deletes a sub-user and releases whatever portion of its bandwidth reservation was never used back to your account balance. Already-consumed usage isn't refunded — only the unused remainder.

curl -X DELETE https://globproxy.com/api/v1/sub-users/SUB_USER_ID \
  -H "Authorization: Bearer YOUR_KEY"

Response

{ "success": true, "gb_released": 3.8 }

If the upstream provider can't be reached the delete fails with 502 and nothing is changed — retry it; a retry after a partial failure completes cleanly. A sub-user that a reseller allocated to you (rather than one you created yourself) can't be deleted through the API, same as in the dashboard — 403 if you try.

Adds bandwidth to a sub-user you already have, instead of creating a new one. Reserves the amount from your balance atomically, same guarantee as creation.

curl -X POST https://globproxy.com/api/v1/sub-users/SUB_USER_ID/topup \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "gb_amount": 5 }'

Body parameters

Response

{ "success": true, "gb_allocated": 10, "gb_added": 5 }

gb_allocated is the sub-user's new total cap, not the amount just added. 402 if your account balance can't cover the top-up. Supports Idempotency-Key (see above).

Up to 10 sub-users per call, each created independently (one failing doesn't stop or undo the others). Each item takes the same fields as POST /sub-users. Idempotency-Key is required; each item counts as one write.

curl -X POST https://globproxy.com/api/v1/sub-users/bulk \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Idempotency-Key: onboarding-batch-2026-10-18" \
  -H "Content-Type: application/json" \
  -d '{ "items": [ { "label": "Client A", "gb_allocated": 5 }, { "label": "Client B", "gb_allocated": 10, "country": "DE" } ] }'

Response

{
  "results": [
    { "index": 0, "status": 201, "sub_user": { "id": "3f1a...", "label": "Client A", "...": "..." } },
    { "index": 1, "status": 402, "error": { "code": "insufficient_bandwidth", "message": "Insufficient bandwidth..." } }
  ],
  "succeeded": 1, "failed": 1
}

Re-sending the same request (same key) returns the same result without creating anything twice. To retry only the failed items, send them under a new key.

POST /sub-users/:id/pause stops a sub-user from using bandwidth while keeping its allocation, credentials and settings; POST /sub-users/:id/resume turns it back on. Both are idempotent (repeating them answers 200 with changed: false). Only a sub-user you paused can be resumed this way — one suspended by GlobProxy answers 403 (see can_resume on the sub-user). A paused sub-user is not affected by account-level suspension cycles. Fires session_suspended / session_resumed with source: "customer".

curl -X POST https://globproxy.com/api/v1/sub-users/SUB_USER_ID/pause \
  -H "Authorization: Bearer YOUR_KEY"

{ "id": "…", "status": "suspended", "changed": true }

Up to 20 sub-users per call: { "action": "delete" | "pause" | "resume", "ids": [...] }. Items are independent and each counts as one write. Every action is safe to repeat, so no Idempotency-Key is needed — if a request times out, send it again (items already deleted report 404). Response: { results: [{ index, id, status, … }], succeeded, failed }; deletes include gb_released.

curl -X POST https://globproxy.com/api/v1/sub-users/bulk-action \
  -H "Authorization: Bearer YOUR_KEY" -H "Content-Type: application/json" \
  -d '{ "action": "pause", "ids": ["SUB_USER_ID_1", "SUB_USER_ID_2"] }'

Find out which values are valid before creating a sub-user. GET /locations lists countries (code → country); GET /locations/:country lists its states with their cities (state / city; add ?cities=false to skip the city lists); GET /locations/:country/asns lists ISPs (asn; empty where ISP targeting isn't offered, 404 for a code that is not a country).

curl https://globproxy.com/api/v1/locations/us/asns \
  -H "Authorization: Bearer YOUR_KEY"

{ "country": "us", "asns": [ { "asn": 7922, "name": "AS7922 COMCAST-7922" }, … ] }

Up to 20 independent top-ups per call. Idempotency-Key is required; each item counts as one write (a call refused with 429 for lack of budget may already have used part of it, so wait for the Retry-After interval before retrying). If any item fails the call is not stored, so re-sending the same request with the same key re-runs only the failed items. If an earlier attempt with the same key finished with an unknown outcome, this answers 409 instead of re-running it — check the sub-users' gb_allocated, then retry with a new key.

curl -X POST https://globproxy.com/api/v1/sub-users/bulk-topup \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Idempotency-Key: monthly-topup-2026-10" \
  -H "Content-Type: application/json" \
  -d '{ "items": [ { "id": "SUB_USER_ID_1", "gb_amount": 5 }, { "id": "SUB_USER_ID_2", "gb_amount": 2.5 } ] }'

Response

{
  "results": [
    { "index": 0, "id": "SUB_USER_ID_1", "status": 200, "gb_allocated": 15, "gb_added": 5 },
    { "index": 1, "id": "SUB_USER_ID_2", "status": 404, "error": { "code": "not_found", "message": "Sub-user not found" } }
  ],
  "succeeded": 1, "failed": 1
}

Returns bandwidth a sub-user hasn't used to your account balance, without deleting it — the reverse of /topup. The sub-user's live usage plus a small safety margin always stays, so you can only release what is genuinely unused.

curl -X POST https://globproxy.com/api/v1/sub-users/SUB_USER_ID/release \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "gb_amount": 2 }'

Response

{ "success": true, "gb_allocated": 3, "gb_released": 2, "max_releasable_gb": 0.41 }

400 with the releasable amount if you ask for more than is unused, 409 if it would immediately re-trigger auto-topup (lower the amount or turn auto-topup off first), 502 if live usage couldn't be confirmed (nothing is changed). Reseller-allocated sub-users return 403. Accepts an Idempotency-Key header, like top-ups: a retry returns the original response instead of releasing twice.

Replaces the sub-user's proxy password; the previous one stops working immediately. Returns the new password (it is also what GET /sub-users/:id now shows). Returns 503 while password rotation isn't enabled for the platform.

curl -X POST https://globproxy.com/api/v1/sub-users/SUB_USER_ID/rotate-password \
  -H "Authorization: Bearer YOUR_KEY"

Response

{ "success": true, "password": "5d0c1e7a-..." }

Turns automatic top-up on or off for a sub-user — when its remaining bandwidth drops to threshold_gb, amount_gb is added automatically from your balance, checked on the same cycle that syncs usage. If your balance can't cover the full amount_gb, the sub-user is topped up with whatever the balance can cover and you're notified (auto_topup_failed, reason partial_funding); with no balance at all nothing is added and the same event is sent with reason insufficient_balance. Both numbers are capped at 100000.

curl -X PATCH https://globproxy.com/api/v1/sub-users/SUB_USER_ID/auto-topup \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "enabled": true, "threshold_gb": 1, "amount_gb": 5 }'

Body parameters

Send { "enabled": false } to turn it off — threshold_gb/amount_gb aren't required (or stored) in that case.

Named sticky sessions on a sticky sub-user. Each has its own connection_username that pins an exit IP for the sub-user's sticky duration.

curl https://globproxy.com/api/v1/sub-users/SUB_USER_ID/sessions \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "sessions": [
    { "id": "9c2e...", "label": "scraper-1", "pinned": false, "collapsed": false,
      "session_token": "aB3dE5gH",
      "connection_username": "gp_...-type-residential-country-us-lifetime-10-session-aB3dE5gH",
      "created_at": "2026-10-18T09:00:00.000Z" }
  ]
}

curl -X POST https://globproxy.com/api/v1/sub-users/SUB_USER_ID/sessions \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "label": "scraper-1" }'

201 with the new session. 400 if the sub-user isn't sticky or already has 200 active sessions.

curl -X PATCH https://globproxy.com/api/v1/sub-users/SUB_USER_ID/sessions/SESSION_ID \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "label": "scraper-1b", "pinned": true }'

Accepts label, pinned, collapsed and terminate: true. DELETE /sub-users/:id/sessions/:sessionId removes a session outright.

Your bandwidth purchases, newest first (read-only). Query: limit, offset, and optional status (pending, paid, failed, refunded, cancelled), created_after and created_before (ISO 8601). One order: GET /api/v1/orders/:id (same fields, plus billed_to — the buyer block printed on the invoice).

Each order carries what its invoice says: the plan, how it was paid (payment_method card or mpesa, with charged_currency / charged_amount), the tax contained in the price (prices are tax-inclusive; null when none applies), invoice_number and invoice_url (opens for the signed-in account owner, not for API keys), and one entry in credit_notes per refund.

curl https://globproxy.com/api/v1/orders?status=paid \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "orders": [
    { "id": "5d0b...", "gb_amount": 100, "amount_usd": 249, "status": "paid", "plan": "growth",
      "payment_method": "card", "charged_currency": "USD", "charged_amount": 249,
      "tax": { "label": "VAT", "rate_pct": 16, "included_usd": 34.34 }, "auto_recharge": false, "dispute": null,
      "invoice_number": "INV-000123", "invoice_url": "https://globproxy.com/invoice/5d0b...",
      "refunded_usd": 0, "refunded_at": null, "credit_notes": [],
      "created_at": "2026-10-01T08:00:00.000Z", "paid_at": "2026-10-01T08:01:10.000Z" }
  ],
  "total": 1, "limit": 50, "offset": 0, "has_more": false
}

Starts a purchase and returns a hosted card-checkout link — send it to whoever pays. Nothing is charged until they complete the payment; the bandwidth is then credited automatically (a bandwidth_credited webhook with source purchase, and the order turns paid in GET /orders/:id). Body: plan (micro, starter, growth, scale or custom with a whole-number gbfrom 1 to 499). Card only — M-Pesa is available in the dashboard. Starting a checkout cancels the account's other unpaid orders, as the buy page does. Idempotency-Key is optional: a retry returns the same order and link. Needs the write scope.

curl -X POST https://globproxy.com/api/v1/orders \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Idempotency-Key: restock-2026-10-24" \
  -H "Content-Type: application/json" \
  -d '{ "plan": "custom", "gb": 37 }'

Response (201)

{
  "order": { "id": "5d0b...", "gb_amount": 37, "amount_usd": 103.6, "status": "pending", "created_at": "2026-10-24T08:00:00.000Z" },
  "checkout_url": "https://checkout.paystack.com/..."
}

The plans POST /orders sells and the custom range, in USD. Add ?gb=37 to price exactly that quantity — the same calculation the checkout charges with.

curl "https://globproxy.com/api/v1/pricing?gb=37" \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "currency": "USD",
  "plans": [ { "slug": "micro", "name": "Micro", "gb": 1, "price_per_gb": 4.5, "total_usd": 4.5 }, … ],
  "custom": { "min_gb": 1, "max_gb": 499 },
  "quote": { "gb": 37, "total_usd": 103.6, "price_per_gb": 2.8 }
}

Your bandwidth transfers to clients, newest first — the same data as the dashboard's Transfers page. Query: limit (max 200), before (cursor). Needs a read key.

curl "https://globproxy.com/api/v1/reseller/allocations?limit=20" \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "transfers": [
    { "id": "e4a1...", "recipient_email": "client@example.com", "gb_amount": 25, "gb_reclaimed": 0, "gb_net": 25,
      "status": "completed", "note": "October top-up", "created_at": "2026-10-18T09:30:00.000Z" }
  ],
  "has_more": false, "next_before": null, "next_before_id": null
}

Moves GB from your stock to a registered client account — the same operation as the dashboard, with the same notifications and webhooks (bandwidth_allocated to you, bandwidth_credited to the client). Requires a key with the allocate scope and an IP allowlist, and an Idempotency-Key. Unknown, suspended and deleted accounts all answer the same 404, so this can't be used to discover who has an account.

curl -X POST https://globproxy.com/api/v1/reseller/allocations \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Idempotency-Key: alloc-client-42-2026-10" \
  -H "Content-Type: application/json" \
  -d '{ "recipient_email": "client@example.com", "gb_allocated": 25, "note": "October top-up" }'

Body parameters

Response (201)

{ "transfer_id": "e4a1...", "status": "active", "pending_id": null, "expires_at": null, "gb": 25, "recipient_email": "client@example.com" }

For an address with no confirmed account the call still succeeds: the GB is reserved out of your stock, the person is e-mailed an invitation, and you get "status": "pending_signup" with a pending_id and an expires_at (30 days). When they sign up and confirm that address the bandwidth is added automatically and you receive a bandwidth_allocated webhook with the new transfer_id. An unclaimed invitation returns to your stock when it expires; list your invitations with GET /reseller/invitations lower it with PATCH /reseller/invitations/:id or withdraw it early with DELETE /reseller/invitations/:id (the pending_id), or do either from your dashboard's Transfers page.

402 insufficient_bandwidth if your stock can't cover it. Shares the dashboard's per-reseller throttle.

Takes back the unused part of a transfer (a typo'd e-mail, a cancelled order). Only bandwidth the client has not used, assigned to a sub-user or since topped up past can move back, and only within the reclaim window — the same rules as the dashboard. gb is optional (default: everything reclaimable): send no body at all to reclaim everything, but a body that is present must be a valid JSON object — a malformed one is a 400 and is never read as "reclaim everything". Needs the allocate scope and an Idempotency-Key; the client receives a bandwidth_reclaimed webhook and an e-mail.

curl -X POST https://globproxy.com/api/v1/reseller/allocations/TRANSFER_ID/reclaim \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Idempotency-Key: reclaim-e4a1-001" \
  -H "Content-Type: application/json" \
  -d '{ "gb": 10 }'

Response

{ "transfer_id": "e4a1...", "reclaimed_gb": 10, "remaining_gb": 15 }

Your stock position and the level that triggers your low-stock e-mail. reserved_in_invitations_gb is stock held for invitations nobody has claimed yet — it is already out of available_gb. Change the alert level with PATCH /api/v1/reseller/settings and a body of { "low_stock_gb": 50 } (null or 0 turns it off; needs a key with the write scope).

curl https://globproxy.com/api/v1/reseller/settings \
  -H "Authorization: Bearer YOUR_KEY"

Response

{ "total_gb": 500, "allocated_gb": 120, "available_gb": 380, "reserved_in_invitations_gb": 20, "low_stock_gb": 50 }

One row per account you have sent bandwidth to — what they were sent, what you reclaimed, and how much of that they have used. The same data as the dashboard's Sub-users page and its CSV export. Query parameters: q (contains-match on email or name), filter (all, unused — nothing used yet, exhausted — everything you sent is used, or idle — no transfer in 30 days), sort (recent, sent, used, remaining or name), limit (max 100) and offset. Most recent activity first by default.

curl "https://globproxy.com/api/v1/reseller/clients?q=acme" \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "clients": [
    { "email": "ops@acme.example", "name": "Acme Ops", "account": "active", "transfers": 3,
      "gb_sent": 75, "gb_reclaimed": 5, "gb_net": 70, "gb_used": 41.2, "gb_unassigned": 28.8,
      "last_transfer_at": "2026-10-18T09:30:00.000Z", "last_note": "October top-up" }
  ],
  "total": 1, "limit": 50, "offset": 0, "has_more": false
}

Invitations created when you allocated to an address with no confirmed account yet. Optional status (pending | claimed | cancelled | expired); without it every state from the last 90 days is returned. id is the pending_id from the allocation response.

curl "https://globproxy.com/api/v1/reseller/invitations?status=pending" \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "invitations": [
    { "id": "9c2e...", "recipient_email": "new.client@example.com", "gb": 25, "note": null, "status": "pending",
      "created_at": "2026-10-18T09:30:00.000Z", "expires_at": "2026-11-17T09:30:00.000Z", "resolved_at": null }
  ],
  "total": 1, "limit": 50, "offset": 0, "has_more": false
}

Lowers the amount reserved on an invitation nobody has claimed; the difference returns to your available balance immediately. The expiry and reminder count are unchanged. To raise it, allocate to the address again; to remove it, use DELETE. Answers 400 if the new amount is not smaller, 404 once the invitation was claimed, cancelled or expired. Needs the allocate scope.

curl -X PATCH https://globproxy.com/api/v1/reseller/invitations/PENDING_ID \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"gb": 10}'

Response

{ "success": true, "gb": 10, "returned_gb": 15 }

Withdraws an invitation nobody has claimed; the reserved stock returns to your available balance immediately. Needs the allocate scope. Answers 404 once the invitation was claimed, cancelled or expired — so repeating a call after a timeout can never return stock twice.

curl -X DELETE https://globproxy.com/api/v1/reseller/invitations/PENDING_ID \
  -H "Authorization: Bearer YOUR_KEY"

Response

{ "success": true, "returned_gb": 25 }

E-mails the invitee again about an invitation nobody has claimed. One reminder every 24 hours (429 until then) and at most three per invitation (409 after that). Only addresses without a usable account are mailed. If the e-mail provider rejects the message the call returns 502 and the reminder is not counted. Needs the allocate scope.

curl -X POST https://globproxy.com/api/v1/reseller/invitations/PENDING_ID/remind \
  -H "Authorization: Bearer YOUR_KEY"

Response

{ "success": true, "reminders_left": 2, "expires_at": "2026-11-20T09:30:00.000Z" }

IP addresses currently allowed to use this sub-user's credentials.

curl https://globproxy.com/api/v1/sub-users/SUB_USER_ID/whitelist \
  -H "Authorization: Bearer YOUR_KEY"

Response

{
  "ips": [
    { "ip": "203.0.113.4", "description": "Office IP" }
  ]
}

curl -X POST https://globproxy.com/api/v1/sub-users/SUB_USER_ID/whitelist \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "ip": "203.0.113.4", "description": "Office IP" }'

Body parameters

Returns the sub-user's full updated whitelist, same shape as the GET above.

curl -X DELETE "https://globproxy.com/api/v1/sub-users/SUB_USER_ID/whitelist?ip=203.0.113.4" \
  -H "Authorization: Bearer YOUR_KEY"

ip is a query parameter here, not a body field.

curl -X POST https://globproxy.com/api/v1/sub-users/SUB_USER_ID/whitelist/bulk \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "items": [
      { "ip": "203.0.113.4", "description": "Office IP" },
      { "ip": "198.51.100.9", "description": "Home IP" }
    ]
  }'

Up to 150 IPs per request. All-or-nothing — the first invalid entry rejects the whole batch.

curl -X DELETE https://globproxy.com/api/v1/sub-users/SUB_USER_ID/whitelist/bulk \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "ips": ["203.0.113.4", "198.51.100.9"] }'

A POST-shaped body on a DELETE — deliberate, so it can carry an arbitrary-length list rather than being limited to what fits in a query string.