Manage tokens and explore endpoints from the API page in my.cubepath.com.

Create a token

Open Organization → Tokens and click Create Token:

  • Token Name — a label to identify the token (e.g. Production Server).
  • Permissions — leave Full access on, or turn it off and pick individual scopes.
  • Allowed IPs (optional) — comma-separated IPs or CIDR ranges that may use the token. Leave empty to allow any IP.

Scope it down

Full access is convenient and rarely what a token needs. Two settings make a leaked token much less useful to whoever finds it:

  • Individual scopes. A monitoring script needs read scopes and nothing else. A token that can only read can't delete a cluster.
  • Allowed IPs. Pinning a token to the server that uses it means a copy taken from a config file is useless anywhere else.

Create one token per consumer rather than sharing one, so revoking a compromised token affects one thing rather than everything.

Authenticate

Send your token with every request using either header:

curl https://api.cubepath.com/projects/ \
  -H "Authorization: Bearer YOUR_API_TOKEN"

You can use X-API-Key: YOUR_API_TOKEN instead of the Authorization header.

That extra header on writes catches people out — a request that reads fine but fails only on writes is almost always missing it.

Base URL

All endpoints live under:

https://api.cubepath.com

Revoke a token

Go back to Organization → Tokens and Delete any token to revoke its access immediately.

Rotate a token by creating the replacement first, switching the consumer over, then deleting the old one — that way there's no window where the integration can't authenticate.

Agents and MCP

To let an AI agent operate your infrastructure, the MCP server is usually a better fit than handing over a raw token — it has its own authorization flow, per-organization consent and permission checks on every request. Tokens remain the right answer for scripts, CI and anywhere there's no browser to complete a login.