All documentation

Account and integration API

Account credential versus integration token

A named account key uses Authorization: Bearer for the panel-account services. GET /panel-api/account validates the account connection. GET /panel-api/server-key remains a compatibility validation endpoint; it does not create or monitor a server. The email/apiToken exchange under /v1/api/auth/token is a separate integration flow, not an SSH login.

GET /panel-api/account
Authorization: Bearer <ACCOUNT_API_KEY>

POST /v1/api/auth/token
Content-Type: application/json
{"email":"user@example.com","apiToken":"<INTEGRATION_API_TOKEN>"}

GET /v1/api/tokens
Authorization: Bearer <INTEGRATION_ACCESS_TOKEN>

Available integration resources

The /v1/api API exposes authentication, wallet reads, token balance and ledger, token packs, checkout and IAP verification. Authenticated requests must use the credential required by that API. Server inventory, SSH key, category and tag CRUD are no longer part of this customer API. Payment operations change financial state and must not be used as connectivity tests.

  • GET /v1/api/wallet
  • GET /v1/api/wallet/ledger
  • GET /v1/api/tokens
  • GET /v1/api/tokens/ledger
  • GET /v1/api/tokens/packs
  • POST /v1/api/tokens/checkout
  • POST /v1/api/tokens/iap/verify

Security and errors

Do not send account keys to arbitrary panel URLs or third-party services. A 401 response requires checking credentials; a 403 requires checking access; a 429 requires waiting before retrying. Validate error bodies and avoid automatically retrying non-idempotent payment requests. Portal key management requires a portal session and its security checks.