Invalid Tenant Custody Scope
URI: https://docs.ankatech.co/errors/invalid-tenant-custody-scope
HTTP Status: 422 Unprocessable Entity
When you see this
A per-tenant operation was attempted with the platform (root) tenant as its scope. The platform tenant is the deployment custody tier, so it can never be the target of per-tenant secret custody, a per-tenant BYOK declaration, an Edition assignment or a tenant observability configuration. The check runs as the first act of every affected entry point, before any custody collaborator is touched, so a refused call seals, persists and probes nothing.
Common Causes
- Supplying the platform tenant id as the
{tenantId}path variable on a per-tenant secret-custody, BYOK, Edition or tenant-observability endpoint. - A client that resolved "the current tenant" to the platform tenant while a platform administrator was signed in, then called a per-tenant surface with it.
Response Example
{
"type": "https://docs.ankatech.co/errors/invalid-tenant-custody-scope",
"title": "Invalid Tenant Custody Scope",
"status": 422,
"detail": "The platform tenant is not a valid scope for per-tenant secret custody",
"instance": "/api/v3/admin/platform/tenants/00000000-0000-0000-0000-000000000000/key-backend/byok",
"timestamp": 1730000000,
"extensions": {
"requestId": "7a15be03-cd68-4270-91af-e5b3082df614"
}
}
Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.
How to Resolve
- Re-issue the request against a real tenant id rather than the platform tenant.
- To configure the deployment itself, use the deployment-plane surfaces — platform settings and
/api/v3/admin/platform/setup/*— which own the deployment custody tier. - In a client, never let a platform-administrator session substitute the platform tenant into a per-tenant path. The refusal is identical whether or not a row exists for the requested key, so it cannot be used to discover what is configured.
For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.