Administration API

The console is the usual way to do all of this, and the CLI wraps the same routes. This page is the API underneath both, for anyone automating a deployment.

There are two scopes. Tenancy routes live under /{tenancy}/v1 and concern the organisation. Namespace routes live under /{tenancy}/{namespace}/v1 and concern one isolated workspace inside it.

Standing and access

Standing is held in the tenancy. It is user, admin or owner, and it decides what a member may do to the organisation.

Access is narrower, and it is what a grant carries: one member, one namespace, and either use or manage. It is how a user comes to be able to use prod but not staging. The two vocabularies never mix. user, admin and owner are standings; use and manage are accesses; neither is ever written where the other belongs.

An admin or the owner manages every namespace in the tenancy and needs no grant for any of them.

Getting in

A registration token is a file in the deployment's secret mount, one per client. Registration is the only way a tenancy comes to exist, and the first account created owns it.

Where the deployment signs people in through an identity provider, that provider's token is accepted in place of a registration token, and the owner's address is taken from it rather than from the body — a token whose address the provider has not confirmed is refused. Such an owner has no password on this service, because they do not sign in with one: they exchange the provider's token for a session at POST /v1/sessions/exchange, and everything below that point is the same for them as for anybody else. A deployment that runs no provider has neither route behaviour and is unchanged.

Namespaces

{ "slug": "prod", "name": "Production" }

The slug is the URL segment. name is for people, and defaults to the slug.

Backends

Created in a namespace, then optionally attached to others.

{
  "name": "anthropic-prod",
  "kind": "anthropic",
  "base_url": null,
  "credential": "sk-ant-…"
}

kind is openai_compat, anthropic or openrouter — see Routing. base_url may be omitted where the kind implies it. credential is write-only: it is encrypted before storage and never appears in any response, so BackendView carries id, name, kind, base_url and credential_source and nothing else.

The address a backend may name

base_url may name anything by default, including an address inside the deployment's own network. That is deliberate: a dedicated deployment usually reaches its model provider there.

A deployment configured with CTX_BACKEND_HOSTS=public narrows it. A backend may then only name an address the internet routes to. The rule is every range the IANA special-purpose address registries mark as not globally reachable, plus the machine's own name. localhost, any name under .localhost, an address in a loopback, this-network, private, shared or link-local range, and a name that resolves to one of those, are each refused with 422 and code backend_host_refused, and nothing is created. The address is checked again when a call is made, so a name that starts pointing inside the network later is refused there too. A deployment serving tenants it does not trust sets it.

A backend that holds no credential

credential_source says where a call through this backend gets its provider credential. It defaults to stored, which is the shape above. The other value is caller, a backend that holds no key of its own and forwards the one each submission brought:

{
  "name": "anthropic-passthrough",
  "kind": "anthropic",
  "credential_source": "caller"
}

A caller backend takes no credential, and sending both is refused with 422, because a backend that holds a credential and ignores it is one nobody can reason about.

Note the two deletes. Detaching removes a backend from one namespace; deleting removes it from the tenancy.

Routing rules

All namespace-scoped, and all needing manage on the namespace. An admin or the owner holds that everywhere; a user holds it where granted. The same layer covers /requests, /usage, /storage and /execution.

{
  "priority": 100,
  "pattern": "claude-*",
  "backend_id": "…",
  "model_rewrite": "claude-sonnet-4-20250514"
}

Lowest priority wins. Routing has the semantics.

Members and grants

An invited member given a password they did not choose must replace it before they can do anything else — that is the 403 password_change_required in Errors.

Keys

Minting answers with the only copy of the secret:

{ "id": "…", "name": "batch-worker", "prefix": "ab12cd34", "key": "sar_ab12cd34_…" }

Listing never does — ApiKeyView carries id, name, prefix, created_at and revoked_at. The secret is stored only as a keyed hash, so a lost key is replaced rather than recovered. The eight-character prefix is the public half, and it is what usage figures and log lines name a key by.

Ownership

Both are the owner's alone.