Automating Your Account with the User API

The User API is a read-and-manage interface for your own account, served under the base path /api/user/v1 on the same domain you use for the dashboard. It answers the questions your scripts actually need answered: how much data is left, what the balance is, which sessions are open, and what state your deposit invoices are in.

It also carries a handful of write operations — clearing sessions and starting account deletion — so you can automate hygiene tasks, not just monitoring. Everything it exposes is information or actions you already have in the dashboard; the API just makes them scriptable.

1. 01Log in to the dashboard and open the API Access page.
2. 02Opt in. API access is disabled by default on every account.
3. 03Copy the generated key and store it in a password manager or secrets store. It is shown in the dashboard, but treat it as sensitive from the moment it exists.
4. 04Whitelist exactly one IP — the public IP of the machine that will make the calls. Requests from any other address are rejected, even with a valid key.

If your server's IP changes, update the whitelist before your jobs start failing. The key itself can be regenerated at any time; the old key stops working immediately, so schedule regeneration for a moment when your automation can tolerate a swap.

Every request carries the key in the X-User-API-Key header. There are no cookies, tokens to refresh, or OAuth flows — one static header, sent over HTTPS, from your whitelisted IP.

curl -H "X-User-API-Key: YOUR_KEY" \
  "https://your-dashboard-domain/api/user/v1/info"

Replace your-dashboard-domain with the domain you normally use to reach your dashboard. Responses are JSON. If a call is rejected, check three things in order: the key is current (not a regenerated-away old one), the header name is exact, and the request is really leaving from the whitelisted IP — NAT and cloud egress can surprise you.

• GET /info — account overview: the same headline numbers the dashboard shows, suitable as a single health-check call.
• GET /usage — bandwidth statistics, the endpoint you will poll most for remaining-data alerts.
• GET /sessions — the list of active dashboard sessions on your account.
• GET /invoices — your deposit invoices and their current state, useful for confirming a crypto top-up credited.
• POST /sessions/clear revokes the specific sessions you name; POST /sessions/clear-all signs out everything at once.
• POST /account/delete — begins permanent account deletion; GET /account/deletion-status reports where that process stands.

Two global limits apply across all endpoints: 10 requests per minute and 100 requests per hour. Individual endpoints carry their own limits on top of that, so a burst against one route can be throttled even while you are under the global ceiling.

• Poll gently. Usage numbers do not change second to second; a five-minute interval catches everything that matters and uses a fraction of the hourly budget.
• Cache responses. If two of your tools both need /info, fetch it once and share the result instead of doubling your call rate.
• Back off on rejection. When a request is rate-limited, wait and retry later — hammering the endpoint only keeps you throttled.

• Usage alerts — poll GET /usage and notify yourself before data runs dry, so long scraping or monitoring jobs never die mid-run. Auto-replenish in the dashboard covers the other half: it converts each credited deposit to GB, so the top-up you send in response needs no second step.
• Balance monitoring — feed GET /info into whatever ops dashboard you already run, so proxy spend sits next to your other infrastructure metrics.
• Session hygiene — a scheduled job that lists sessions and clears stale ones keeps your account's active-session list short and auditable.
• Deposit confirmation — after sending crypto, watch GET /invoices instead of refreshing the dashboard until the payment credits.

One caution on alerts: if a job stalls, verify the proxy side before assuming you are out of data. The troubleshooting guide covers the usual causes, and the built-in proxy checker will test your credentials directly.

The key can read your balance, enumerate your sessions, and start deleting your account. Treat it exactly like a password: keep it in an environment variable or secrets manager, never commit it to a repository, and never paste it into logs, tickets, or chat.

• Regenerate on exposure. If the key leaks — or you merely suspect it did — regenerate it from the API Access page. The old key dies instantly; update your scripts and move on.
• The IP whitelist is your second lock. A stolen key is useless from any address except the one you whitelisted, which is why the whitelist allows exactly one IP. Do not point it at a shared or public egress address.
• Harden the account itself. Enable 2FA and store your backup codes properly — the account security guide covers the full setup.