The override was applied; the body carries the new effective value, the optimistic-lock version, and whether a restart is still pending.

The candidate value fails the catalog validator for this key — wrong type, out of range, or not one of the declared enum values.

Missing, malformed or expired bearer token

The caller is not a platform administrator, or lacks admin.platform.config.dangerous for a DANGEROUS key, or lacks admin.platform.deployment-secret.write for a secret. Every refusal is oracle-safe and reveals nothing about whether a value is assigned.

No such setting key in the catalog

The setting is NOT WRITABLE, which is one refusal covering TWO distinct propagation types: READ_ONLY_DIAGNOSTIC, an observation of the platform that nothing can set; and DEPLOYMENT_OWNED, a real parameter whose owner is the deployment — the entry names the environment variable to change instead, in deploymentVariable. Also covers an ANKA-managed tier credential, whose lifecycle belongs to the rotation endpoint; and an ops-provisioned Docker secret this product does not own. The detail is a fixed, type-neutral literal: it names neither the key, nor the propagation type, nor the variable, so the refusal cannot be used as an existence oracle.

Either the optimistic-lock version does not match the stored override row, or the setting is deployment-type-gated and does not apply to this deployment.

The write is refused by a setting-specific precondition. For the per-tenant BYOK backend allowlist (§165) this is raised when the proposed list excludes a backend tenants have ALREADY declared: the body carries the affected tenant COUNT (never an identity) and NOTHING has been persisted. Re-submit with acknowledgeAffectedTenants set to that count to confirm. Those tenants keep operating on the excluded backend - an allowlist restricts new declares and binds only and never invalidates a bound backend.