Authentication
Every Helium MVNE API request authenticates with a bearer token — an operator-scoped API key minted in the dashboard.
Authorization: Bearer rk_sandbox_8fa...
Key tiers
| Tier | Prefix | Scope |
|---|---|---|
| Publishable | pk_{mode}_… | Safe to ship in client-side code. Read-only, narrow scope. |
| Restricted | rk_{mode}_… | Server-side. Scoped to one or more capability tags (e.g. subscribers:write). Preferred. |
| Secret | sk_{mode}_… | Full operator scope. Server-side only. Rotate aggressively. |
{mode} is always sandbox or live. A sandbox key can never see
live data and vice versa — see Environments &
mode.
Creating keys
Keys are created in the dashboard by an operator admin or owner. Each key records its capability scope, last-used timestamp, and the human who created it. Keys are shown exactly once on creation.
Rotation
Rotate a key by creating a replacement, updating your deployment, then revoking the old one. There is no overlap grace window beyond that — pre-stage the swap.
What never auths a Helium MVNE call
- Session cookies. There is no user-session auth on
/v1/*. - MVNO end-user tokens. Helium MVNE has no concept of end-user authentication; those subscribers never touch a Helium MVNE domain.
- Shared secrets. Every integration uses its own key.
The dashboard is the one exception: it reaches /v1/* via an
admin-sudo claim minted by the signed-in operator admin, not via an
API key. That path is an internal implementation detail — your
integration always uses a key.