Tenant Backend Already Bound
URI: https://docs.ankatech.co/errors/tenant-backend-already-bound
HTTP Status: 409 Conflict
When you see this
A per-tenant bring-your-own-backend declare or change was attempted for a tenant that already holds key material. The immutability authority is the key-material-exists read against core-api: once the tenant has any key material, its key-material backend is immutable, because changing it would strand that material. The refusal happens before any credential is sealed and before any descriptor is mutated.
Common Causes
- Declaring a different BYOK backend for a tenant that has already created at least one key.
- Changing a tenant's existing BYOK declaration after its first key was wrapped.
This is the BYOK plane. The managed-Edition plane answers key-backend-already-bound for its own equivalent condition, and the deployment plane answers backend-already-bound.
Response Example
{
"type": "https://docs.ankatech.co/errors/tenant-backend-already-bound",
"title": "Tenant Key-Material Backend Immutable",
"status": 409,
"detail": "This tenant already holds key material; its key-material backend can no longer be changed.",
"instance": "/api/v3/admin/tenants/7d1c9b40-52e8-4a36-9f07-c3b81e6d240a/key-backend/byok",
"timestamp": 1730000000,
"extensions": {
"requestId": "9c72e158-40ab-4d36-8e15-b3097fa25c64"
}
}
Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.
How to Resolve
- Read the tenant's current declaration with
GET /api/v3/admin/tenants/{tenantId}/key-backend/byokto confirm which backend is in force. - If the declared backend is the intended one, no action is needed — the refusal protects the key material already wrapped under it.
- If a different backend is genuinely required, provision a new tenant on it. Note that a bind self-test never creates key material, so a tenant that has been bound but holds zero keys can still change its backend.
For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.