Skip to content

Rotation Execution Mismatch

URI: https://docs.ankatech.co/errors/rotation-execution-mismatch
HTTP Status: 422 Unprocessable Content

When you see this

This refusal indicates a platform-side inconsistency in how a key rotation was tracked; it is not caused by your request. The detail is one fixed sentence. Nothing was written: no material, no version advance.

The Admin API assigns a new execution identifier to every new rotation and keeps the one it reserved under an Idempotency-Key, so a request you send cannot reach this refusal by itself: a reused Idempotency-Key with another request is refused earlier, with Idempotency Key Reused. If you receive it on POST /api/v3/admin/tenants/{tenantId}/keys/{kid}/rotations (rotateKey), where the Admin API relays it verbatim as a 422, it indicates a platform defect, not a defect of your request.

Response Example

{
  "type": "https://docs.ankatech.co/errors/rotation-execution-mismatch",
  "title": "Rotation Execution Mismatch",
  "status": 422,
  "detail": "This executionId already names a different rotation. Nothing was changed; a new rotation needs a new executionId.",
  "instance": "/api/v3/admin/tenants/6f1b2c4e-8a3d-4f7e-9c21-5b0d7e9a1f34/keys/payments-signing-key/rotations",
  "extensions": {
    "requestId": "8b3f0c27-4e1d-4a9b-b6c5-3e7a1d9f2c04"
  }
}

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

How to Resolve

  1. Read the key (GET /api/v3/admin/tenants/{tenantId}/keys/{kid}) to see whether it was rotated.
  2. Contact support with the response's correlation identifier (extensions.requestId in the Admin API body). Retrying does not change the answer.

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