Create and manage API tokens safely

An API token lets a script, a CI pipeline, the CLI, or a third-party integration talk to the OrbixPanel API on your behalf — without your password and without a browser session. That power is also the risk: a leaked token is a leaked key to your account. Treat tokens like passwords, and grant each one only what it needs.

Create a token

In the panel, open API Tokens and create one. You choose three things:

Name — a label so you know what it’s for later (e.g. ci-deploy, backup-script). Up to 60 characters.
Scopes — what the token is allowed to do (see below). Default is read-only.
Expiry (optional) — have it stop working automatically after N days (1–3650). A short-lived token for a one-off job is much safer than a permanent one.

When you create it, the full token (it starts with orbx_) is shown exactly once. Copy it then — OrbixPanel stores only a hash and can never show it again. If you lose it, revoke it and make a new one.

Use it as a bearer token:

curl -H "Authorization: Bearer orbx_xxxxxxxxxxxx" \
  https://your-panel:8080/api/sites

Scopes — grant the least you can

This is the whole point. Don’t hand a log-shipping script write access to your whole account.

Coarse scopes:

Scope	Allows
`read`	Any read-only (GET) request
`write`	Everything — full account access
`*`	Everything (superuser)

Fine-grained scopes — pick a resource and a verb for exactly-enough access:

Resources: content, orders, billing, support, dns, sites, databases, email, backups, cron, certs.
Verbs: :read (view), :write (change — and write includes read), :* (all).

Examples:

A deploy script that only restarts sites → sites:write
A dashboard that only reads DNS and sites → dns:read, sites:read
A backup runner → backups:write

Rule of thumb: start from read, add the single <resource>:write the job actually needs, and nothing more. Avoid write and * unless a tool genuinely needs full control.

Store tokens safely

Never commit a token to a git repo, paste it in a ticket, or hard-code it in client-side/front-end code.
Put it in a secret store or an environment variable (ORBIX_TOKEN), not in source. In CI, use the platform’s encrypted secrets.
One token per integration, so you can revoke one without breaking the others.

Rotate and revoke

Rotate periodically: create a replacement, switch the integration over, then revoke the old one. Set an expiry so rotation is enforced for you.
Revoke immediately if a token may have leaked (committed by mistake, shown in a log, left on a shared machine). Revoking is instant — the token stops working on the next request.
Review your token list regularly and delete any you don’t recognize or no longer use. Each token shows its name, scopes, prefix, and last-used time.

If a token leaks

Treat it as an account incident: revoke it, rotate anything it could have touched, and check for unexpected changes. → What to do if your server is compromised