API Keys

API keys provide programmatic access to the platform. A key belongs to one project, carries scoped permissions, and can only ever act on the project it was issued from.

Every endpoint on this page requires a signed-in session. API keys cannot manage API keys — a key that could mint keys could escalate its own scopes and survive its own revocation.

List API Keys

GET /v1/projects/:projectId/api-keys

Lists the keys bound to this project. Owners and admins see every key, including other members'; everyone else sees only their own. Key values are never returned — only the leading characters, enough to tell two keys apart.

Auth: Session required

Create API Key

POST /v1/projects/:projectId/api-keys

Creates a new API key, bound to this project, with optional permission scopes. The key value is returned once and cannot be read back afterwards.

Auth: Session required, write access

Request Body:

{
  "name": "CI/CD Key",
  "permissions": {
    "apps": ["read", "write"],
    "servers": ["read"]
  }
}

Available Scopes:

Scope	Description
`servers:read`	List and view servers and SSH keys
`servers:write`	Create and delete servers and SSH keys
`apps:read`	List and view apps, logs, metrics
`apps:write`	Create, update, and delete apps
`domains:read`	List and view domains
`domains:write`	Register, migrate, and manage domains
`databases:read`	List and view database clusters
`databases:write`	Create, resize, and delete database clusters
`redis:read`	List and view Redis databases and browse their keys
`redis:write`	Create and delete Redis databases, edit keys, and run console commands
`object-storage:read`	List buckets and their contents
`object-storage:write`	Create and delete buckets, upload and delete files
`registry:read`	List registries, repositories, and images
`registry:write`	Create registries and repositories, delete images
`iam:read`	List access keys
`iam:write`	Create, rotate, and delete access keys
`email:read`	View email domains and credentials
`email:write`	Create credentials, verify DNS, manage limits
`webhooks:read`	List endpoints and their delivery history
`webhooks:write`	Create, update, test, and delete endpoints
`integrations:read`	View connected git providers and other integrations
`integrations:write`	Connect and disconnect integrations
`secrets:read`	List project secrets (values are never returned)
`secrets:write`	Create, update, and delete secrets
`variables:read`	List project variables
`variables:write`	Create, update, and delete variables
`members:read`	List project members
`members:write`	Invite, remove, and update members
`support:read`	List and view support tickets
`support:write`	Create and reply to tickets
`billing:read`	View invoices, usage, and billing history
`billing:write`	Manage the payment method and refund the credit balance

A key with no permissions has no API access. Scopes and roles are enforced together, not as alternatives: a key never reaches further than its owner's role in the project allows, and billing:write covers card changes and credit refunds on top of requiring that the key's owner is the project's biller. A key held by anyone else is refused regardless of its scopes.

A key presented against a different project — a /v1/projects/:projectId/... route, or a request that names another project, such as opening a support ticket — is refused with 403 API_KEY_WRONG_ORGANIZATION. Endpoints that are not addressed by a project answer as if the other projects did not exist: GET /v1/projects, GET /v1/domains and GET /v1/support-tickets list only the key's own project, and reading a ticket or a domain outside it returns 404 NOT_FOUND.

object-storage, registry, and iam replaced a single storage scope. Keys issued before the change keep working — storage still grants all three — but new keys must name the scopes they need.

Update API Key

PATCH /v1/projects/:projectId/api-keys/:id

Updates the API key name and/or permissions. Sending permissions replaces the key's scopes wholesale rather than merging them.

Auth: Session required, write access

Request Body:

{
  "name": "Updated Name",
  "permissions": ["apps:read"]
}

Roll API Key

POST /v1/projects/:projectId/api-keys/:id/rotate

Issues a replacement key with the same name, permissions, project and owner as this one, then revokes this key. Use it when a key may have been exposed, or on a schedule.

The replacement has a new id, and its secret is returned once in the response — it cannot be retrieved afterwards. The old key stops working, so update anything using it before rolling.

Auth: Session required, write access

Response:

{
  "success": true,
  "data": {
    "id": "key_...",
    "name": "CI/CD Key",
    "key": "db_..."
  }
}

Delete API Key

DELETE /v1/projects/:projectId/api-keys/:id

Revokes the key. Anything still using it starts receiving 401 UNAUTHORIZED. Owners and admins can revoke any key pointing at the project, including keys created by other members.

Auth: Session required, write access

List API Keys

Create API Key

Update API Key

Roll API Key

Delete API Key

On this page