The OrbitLab API gives programmatic access to everything you manage in the dashboard: services and deployments, environment variables, logs and metrics, domains and DNS, databases, files, WordPress tools, organizations, orders and renewals. The CLI is built on it.
Browse every endpoint in the API reference section of the sidebar.
Base URL
Requests and responses use JSON unless an endpoint says otherwise (logs are text/plain, invoices are PDF, uploads use multipart/form-data).
Authentication
Authenticate with an API token in the Authorization header:
Create a token
- Open Dashboard → Settings → API tokens.
- Click Create token, give it a name, and choose:
- Scope: all your organizations, or a single one.
- Expiration: 30, 90 or 365 days, or none.
- Copy the token. It starts with
olab_ and is only shown once.
orbitlab login creates a token for the CLI the same way, after you approve it in the browser. Tokens created by the CLI expire after 90 days.
A token acts with your permissions: it can do what your role allows in each organization. OrbitLab only stores a hash of the token. Revoke tokens you no longer use from the same page, or with DELETE /v1/tokens/{id}. Tokens stop working immediately when revoked, when they expire, or when you leave the organization they’re scoped to.
Treat tokens like passwords: store them in your CI’s secret store, never in your repository.
Dashboard-only actions
For security, some actions require signing in to the dashboard and can’t be done with a token: creating tokens, deleting your account, unlinking sign-in methods and installing the GitHub App.
Organizations
Resources belong to organizations. Requests act on your first organization unless you choose another with the X-OrbitLab-Org header (organization id or slug):
Tokens scoped to one organization always act on it; selecting another organization returns 403. List your organizations with GET /v1/organizations.
Some endpoints require the owner or admin role, for example reading environment variables and database credentials, editing DNS, or managing members. The API reference lists the role for each endpoint.
Conventions
- Ids are UUIDs, except plan ids (
app-1, starter…) and DNS record ids.
- Amounts are integers in cents, with a
currency.
- Dates are ISO 8601 strings in UTC.
- Collections are returned whole under a named key, for example
{ "services": [...] }.
Errors
Errors return an HTTP status and a JSON body with an error message:
Idempotent checkout
POST /v1/checkout creates an order and starts a payment. Send a unique Idempotency-Key header so a retried request returns the same order instead of creating another one.
Examples
Deploy a service and follow it:
Set environment variables:
Add a DNS record:
Order an app plan paid with Mobile Money:
A payment request is sent to the phone. Poll GET /v1/orders/{orderId} until the order is paid. Card payments are currently unavailable; free orders need no phone number.
Tools that can’t store a token ahead of time can use the same device login as the CLI:
POST /v1/auth/device with {"clientName": "my-tool"} returns deviceCode, userCode and verificationUriComplete.- Show the user the code and the link. They approve the request in the dashboard.
- Poll
POST /v1/auth/device/token with {"deviceCode": "…"} every interval seconds. While waiting, it responds 400 with "error": "authorization_pending"; on "slow_down", add 5 seconds to the interval. Once approved, it returns the token exactly once.