Update tenant properties
Modify tenant metadata, status, or hierarchy.
STATUS TRANSITIONS: - ACTIVE → SUSPENDED: Blocks new reservations, existing active reservations can still commit/release - SUSPENDED → ACTIVE: Resume normal operations - * → CLOSED: Irreversible, archives tenant, and triggers
the tenant-close cascade (see CASCADE SEMANTICS in
info.description). As part of the close, the server MUST
drive all owned objects to their terminal states — either
atomically with the status flip (Mode A) or via a
Rule-2-guarded post-flip cascade (Mode B). Every mutating
call on an owned object after the close commits returns
HTTP 409 TENANT_CLOSED. Re-issuing close on an
already-CLOSED tenant is a no-op at the tenant level;
under Mode B it additionally drives any outstanding child
transitions to completion.
Authorizations
Administrative API key with full system access. Also accepted as an alternative to ApiKeyAuth on an explicit per-operation allowlist — the authoritative list is the union of operations whose security: block declares AdminKeyAuth (consult per-operation security blocks rather than this prose, which has historically drifted as the dual-auth surface expanded). When using AdminKeyAuth on list or fund endpoints, a tenant scoping parameter (typically tenant or tenant_id) is required for scoping (400 if missing) — the per-operation description specifies which. Lookup-style endpoints that uniquely identify a resource by non-tenant key (e.g. GET /v1/admin/budgets/lookup, where the (scope, unit) pair is unique) do NOT require a tenant parameter. Allowlisting is per-operation (exact method:path matching — no prefix matching, no wildcards) so new endpoints do not accidentally inherit admin-accessible status.
Parameters
Path Parameters
Request Body
Responses
Tenant updated