Interlaken

Interlaken for developers

What the orchestrator API is, and the shortest path to calling it.

Interlaken runs compute, storage, networking, managed services, applications and agents on hardware in its own availability zones. All of it sits behind one HTTP API, and the console in your browser is a client of that API like any other. There is no second, lesser surface for customers.

Where to start

How the API is shaped

Everything lives under /api/v1. Resources are plural nouns, identified by a UUID: /api/v1/vms, /api/v1/vms/{id}, /api/v1/vms/{id}/disks. Collections answer with { "items": [...], "total": n }, and a resource answers with the object itself. Creating something returns its id.

Three things are worth knowing before you write any code.

Every call is scoped to one tenant. The tenant is carried in the token, never in the path, so the same request made with two different tokens reads two different sets of resources. Nothing you can pass in a request body crosses that boundary.

Permissions are checked per route. A token carries a set of permission keys such as vms:create. A route that needs one you do not hold answers 403 and names the key it wanted, which makes the fix obvious. See Permissions and scopes.

Work is asynchronous, and reconciled. Creating a VM returns as soon as the intent is recorded. A reconciler then drives the real hardware towards that intent and the resource's status field moves through transitional states on its own. Poll the resource, or read /api/v1/events for a live stream, rather than assuming a 201 means the machine is running.

What you cannot reach

The reference here documents the tenant-facing API. Routes guarded by a platform: permission, the operator surface under /api/v1/admin, and the machine-to-machine routes under /api/v1/internal are deliberately absent: those permissions are excluded from the wildcard grant and cannot be given to an API client, so no credential you hold will open them.

On this page