Skip to main content
The Management API is the provisioning surface for your organization. Creating a project, minting a runtime key for it, deploying a dynamic route, writing a compliance rule, and retiring any of them are the things you would otherwise do by hand in the platform UI. Here they are HTTP endpoints, so onboarding a service, rolling out a routing change or tearing down a stale environment can live in CI or Terraform instead of a runbook. It is a control-plane API: it manages the containers your model calls run in, not the calls themselves. Sending a prompt still goes through the v3 API with a runtime key.
The Management API is available on selected plans. If your organization’s plan does not include it, every endpoint answers 403 with the current and allowed plans in the body.

​
Authentication

The Management API uses its own credential — a management key, prefixed op-mak-. Mint one in the platform UI under Settings → API keys, then send it as a bearer token:
A runtime op-… key is not accepted here — it will be rejected with 403. The two credentials are deliberately different things:
A management key can create and delete projects across your entire organization. Store it as a secret in your CI provider — never in application config alongside runtime keys, and never in a client.

​
Scopes

Every management key carries an explicit list of scopes, chosen when you mint it. A request whose key lacks the scope an endpoint requires is rejected with 403 and a required_scope field naming what was missing. Grant the narrowest set that does the job. A CI pipeline that only rotates keys needs apikeys:write and nothing else.

​
Response shape

Every response is an envelope with meta and data. Single resources leave meta empty; collections use it for total_count.

​
Provision a project and a runtime key

The common pipeline is two calls: create the project, then mint a key inside it.
1

Create the project

Project names are unique within an organization — reusing one returns 409. The response carries the project uuid you need for the next call.
2

Mint a runtime key inside it

The full op-… key is returned once, in this response, and is never retrievable again. Write it to your secret store in the same step that creates it. Listing keys later returns only their prefixes.
3

Use it for model calls

The minted key is an ordinary runtime key, scoped to that project. Hand it to the service as OPPER_API_KEY and call the v3 API with it.

​
Lifecycle notes

  • Updates are partial. PATCH a project with name, description, or both; omit a field to leave it unchanged, and send "description": null to clear it. A body with neither field is rejected rather than treated as a no-op.
  • Deleting a project deletes its keys. The project is soft-deleted, but every runtime key bound to it is permanently destroyed and stops working immediately.
  • Retention is not set here. It is a control-plane rule — see Opper retention.

​
Deploy a dynamic route from code

A dynamic route is a graph the gateway walks per request to pick the model. The editor and this API save the same graph, so a route built in the UI can be exported, versioned in git and redeployed from a pipeline. The smallest useful route is a Pool node with two models: the first that answers wins, and a model a compliance rule blocks is skipped.
1

Create the route with its first version

deploy: true validates the draft and publishes it as version 1 in one call. Leave it out to save a draft and deploy later with POST /management/v1/dynamic-routes/support-router/deploy.
2

Check the path a request would take

No provider is called. The response lists the nodes visited and the model that would answer.
3

Call it by name

The route is a model id: pass dynamic/support-router as model on any endpoint, with a runtime key. The response’s meta.routing says which version ran and which model served.
Every deploy is a numbered version. POST …/versions/{n}/rollback re-deploys an older graph as a new version, so the history stays linear.

​
Manage rules from code

Rules are rows the same API can read and write: retention, spend limits, model access, checks and routing defaults. A rule created here is enforced from the next request, exactly like one saved on the Rules page. Each rule has a kind (guard, observe, route, comply), a scope (the organization, a set of projects, or a set of functions) and a config whose shape follows the kind; the reference documents each.
id, kind and scope are fixed once created; change anything else with PATCH. A zero-day retention rule over a scope that still holds stored files is refused with 409 until you resend with confirm_file_deletion: true.

​
Revoke a leaked management key

If a management key is exposed, disable it with the key itself:
Possession of the token is the authorization — no scope is required, and it works regardless of your plan, so a leaked key can always be shut off. This disables the key the request authenticated with and every token issued under it.

​
Endpoints

Projects

List, create, fetch, update, and delete projects.

API keys

List, mint, and delete a project’s runtime keys.

Dynamic routes

Create, simulate, deploy, version and roll back routes.

Rules

List, create, update and delete rules.