Skip to content

Token Signing Key State Changed

URI: https://docs.ankatech.co/errors/token-signing-key-state-changed
HTTP Status: 409 Conflict

When you see this

A revocation of a user-token signing key named, in expectedState, the state the caller saw the key in, and the key is no longer in that state. What a revocation does depends on the state — revoking ACTIVE promotes the NEXT key at once, revoking NEXT publishes a replacement, revoking PREVIOUS removes the key — so a revocation decided on one state is never applied to another. Nothing was changed and no audit event was written.

The check is a precondition with the semantics of an RFC 9110 §13.1.1 If-Match, carried in the request body because it applies to one key of the set. It runs inside the same compare-and-set as the revocation, so it cannot be raced.

Common Causes

  • A rotation promoted the key between the read and the revocation: the NEXT key the operator meant to discard is now ACTIVE and signing. The rotation may have been another administrator's, or the platform's own scheduler rotating on the configured period.
  • A rotation demoted the key the operator saw as ACTIVE to PREVIOUS.

Response Example

{
  "type": "https://docs.ankatech.co/errors/token-signing-key-state-changed",
  "title": "Token Signing Key State Changed",
  "status": 409,
  "detail": "The token signing key is no longer in the state the request expected",
  "instance": "/api/v3/admin/platform/token-signing-keys/a1ZrT8mQeV4nXb6cJw2sLoP9uY3tR7wE5qN0zK8hG2c/actions/revoke",
  "timestamp": 1798596060,
  "extensions": {
    "requestId": "2f8d4b6a-1c3e-4a59-8b7d-6e0f9a2c5d41",
    "currentState": "ACTIVE"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

extensions.currentState is the state the key is in now — NEXT, ACTIVE or PREVIOUS — the same value the list operation discloses. The kid is not echoed. There is no Retry-After: repeating the same request fails the same way.

How to Resolve

  1. Read extensions.currentState and decide again whether the revocation is still wanted in that state: revoking a key that is now ACTIVE promotes the NEXT key immediately, which is an incident action, not a routine one.
  2. If it is, repeat the revocation with expectedState set to the current state. Do not resend automatically on the operator's behalf.

See Admin API — Platform Token Signing Keys*.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.

* restricted content — see higher-tier documentation