The word "token" gets overloaded in Nodetonet. There is the device-pairing token you paste into the Android app, and then there are two flavours of API credential that look similar in the panel but do wildly different things. This post is about those two — the ones that authenticate against Nodetonet's REST endpoints.
Getting them mixed up is the most common cause of "why is this customer seeing every proxy I own?" support tickets. The rule is one sentence: personal keys are for you, customer tokens are for your customers. The rest is detail — and the security implications of ignoring that detail are serious.
The two credentials at a glance
Before going deep, here is a side-by-side summary:
| Property | Personal API Key | Customer API Token |
|---|---|---|
| Issued to | Your own account | One downstream customer record |
| Scope | Full account access | Only that customer's assigned proxies |
| Can create proxies? | Yes | No |
| Can read billing? | Yes | No |
| Can see other customers? | Yes | No |
| Thread / quota limits? | None (full account) | Set by you when creating the customer |
| Can be time-limited? | No (permanent until rotated) | Yes (expiry date on creation) |
| Blast radius if leaked | Entire account | One customer's quota only |
Personal API Key — your account, full access
Every Nodetonet account has exactly one personal API key, visible at the top of the dashboard. Think of it as a long-lived bearer token that authenticates as you, with every permission your account holds.
It can do everything the panel UI can do, and a few things the UI doesn't expose directly:
- List, create, modify and delete any mobile proxy, rotating proxy or HTTP tunnel under your account.
- Pair and unpair device tokens, browse usage statistics.
- Trigger credit top-ups, read billing history.
- Manage your customer accounts and rotate their tokens.
The header format for every authenticated call is the same:
curl -H "Authorization: Bearer npk_live_8x2q...z9w7" https://nodetonet.com/api/v1/proxiesIf this key leaks, treat it exactly like a database root password leak. Rotate it immediately from the dashboard card — the old key is invalidated the moment you click rotate, every running script using it stops, and you re-deploy with the new value. There is no two-key grace period by design.
When to use the personal key
- Internal automation scripts on infrastructure you own and control.
- Server-to-server integrations that never leave your own systems.
- Provisioning new customer records, then handing them a customer token.
Never embed the personal key in client-side code, browser extensions, mobile apps, or anything that ships outside your own servers. If third-party eyes could ever reach it, use a customer token instead.
Customer API Token — scoped to one downstream customer
If you are running Nodetonet as a reseller or white-label backend — selling proxies to your own end users under your own brand — you create one customer record per buyer and Nodetonet issues a customer token bound to that record. The token is tightly scoped: it can only see and use proxies you have explicitly assigned to that customer, within the limits you configured (thread count, quota, expiry date, IP whitelist).
From the customer's perspective, the token is an opaque string they paste into your product or call from their code. But the auth surface the token exposes is dramatically smaller:
- They can list their proxies, not yours or any other customer's.
- They can fetch usage stats for the proxies you assigned them.
- They cannot create, delete or modify proxies — that is always your responsibility.
- They cannot see other customers, your billing balance, or anything outside their own scope.
Customer tokens share the same Authorization: Bearer header format — the backend reads the token prefix to determine which scope and limits apply.
Guardrails you control
When you create a customer record, you set the limits that apply to their token. These include:
- Thread limit — maximum concurrent connections. See thread limits per client for tuning advice.
- Bandwidth quota — a cap on data used. See quota limits per client.
- Expiry date — for time-limited access. See time-limited proxy clients.
- IP whitelist / domain allow-deny — restrict where the token can be used. See IP allow and deny lists.
Personal keys have none of these guardrails. They are permanent until you rotate them and have no thread cap, no quota, and no IP restriction.
The decision tree — which credential do I use?
Answer these questions in order:
- Is this code running on infrastructure I personally own and control? If yes, a personal key is acceptable.
- Will a third party ever see, receive, or touch this credential — even indirectly? If yes, always use a customer token.
- Does this script need to provision new proxies, manage billing, or rotate other tokens? Only personal keys can. Build a backend that uses your personal key to provision, then hands the customer their scoped token.
Security implications and blast radius
The entire reason these two types exist is to limit damage from a credential leak.
A leaked personal key gives an attacker everything: they can spin up proxies to drain your prepaid balance, dump your customer list, delete all your HTTP tunnels, and rotate credentials to lock you out. Recovery requires a key rotation and an audit of everything touched during the exposure window.
A leaked customer token gives an attacker access to one customer's quota — capped at the thread limit and expiry you set. They cannot reach your panel, other customers, or your billing. You can invalidate the token by rotating it from the customer management screen without affecting any other part of your operation.
The pattern to follow: your personal key never leaves your server. Your server uses it to provision customers. Each customer receives only their own scoped token. Think of it as the same separation you'd apply to a database — root password stays on the server, application users get only what they need.
Rotating credentials safely
Both credential types can be rotated, but the process and impact differ significantly:
- Personal key rotation is immediate and breaking — the old key stops working the moment you rotate. Plan for downtime on any script or integration using it. Update all usages before rotating if you want zero-downtime (copy new key to all destinations first, then rotate).
- Customer token rotation affects one customer only. Notify the customer, give them the new token, then rotate. Their other services are not impacted.
For a full rotation playbook see when and why to rotate tokens.
Common mistakes to avoid
- Sending the personal key in a customer-facing product. The most dangerous mistake. Audit your code for anything that calls Nodetonet APIs from the client side.
- Not setting expiry on customer tokens. Time-limit every token that belongs to a paying customer so you don't have stale access lingering after a subscription ends.
- Using the personal key for all automation, forever. Once you have multiple integrations, create per-integration tokens where possible to limit each script's blast radius.
- Confusing the device-pairing token with the API key. The token you pair with the Android agent in your first token and Android pairing is a different credential — it identifies a proxy resource, not an API caller.
What's next
- Understanding your API key — format, rotation and common pitfalls for the personal key.
- How customer proxy clients work — the wider reseller feature this token belongs to.
- Creating token groups (device pools) — assign multiple devices to a rotating pool that a customer token can access.
- REST API: your first call — a hands-on walkthrough using the personal key.
- Create a free account and see both credential types in the dashboard.