Administering DVARA
Every CRUD endpoint under /v1/admin/** now returns 404. If you have automation calling it, it is broken — see what to use instead below.
Why it went
DVARA's model is provision in the UI, then let automation act on behalf of that user. A person is created in the Console or Portal, mints a personal access token, and scripts authenticate as them.
An administrative CRUD API was a second way to do what the Console and Portal already do — carrying its own authorisation surface, which had begun to drift from the UI's. There was no production use of it, so it was removed outright rather than deprecated.
What to use instead
| you want to | use |
|---|---|
| provision workspaces, users, routes, policies, pricing, budgets, webhooks, MCP servers, schemas, prompt templates in bulk | the Console's GitOps page — Export → edit the JSON → Import. The services behind it were untouched; only their REST wrappers were removed. |
| create a user, a workspace, an API key | the Console (platform roles) or the Portal (workspace self-service) |
| script something as a user | a personal access token — Authorization: Bearer dvara_pat_… — against the surfaces that remain |
| read metrics | GET /actuator/prometheus on each app (Bearer $DVARA_ACTUATOR_METRICS_API_KEY) |
| read gateway status or licence state | GET /actuator/gateway-status (Bearer $DVARA_ACTUATOR_API_KEY) |
GitOps export/import is the bulk-provisioning path. It is a single JSON document covering the whole fleet or one workspace, so it version-controls cleanly and is the closest replacement for scripted provisioning.
API keys and user credentials are redacted. The export is meant to be committed to a repository, so it carries no key material, no password hashes and no invitation tokens. A user the import creates with no password is sent a fresh invitation instead.
Users reconcile on email, not id — so an export restored onto a different install updates the account that already owns that address rather than colliding with it.
One endpoint survives
GET /v1/admin/config/bundle/signing-key (owner-only) is still served. It belongs to the config-bundle channel rather than the CRUD API, and exists so an operator can pin the bundle signing key from infrastructure-as-code without reading it out of a startup log.
Not affected
These share the admin prefix in the source tree but are not part of the removed API. They are the data-plane decoupling channels and are still served:
POST /internal/ingest · GET /internal/config · GET /internal/deny-list · GET /internal/pii/dek · /internal/batch · /internal/approvals
The data-plane API is unaffected
/v1/chat/completions, /v1/responses, /v1/embeddings and the rest are unchanged and fully supported — see the Data Plane API.