Zintara API key rotation: verify the replacement before revoking the old key

Define the decision

Zintara returns a raw key at creation and stores a hash. An existing key cannot be recovered from that hash through the normal interface. Rotation means creating a replacement and revoking the old credential, not changing a displayed label.

Work through the procedure

1. Inventory the consumer and the scopes it actually needs.
2. Create a replacement in the same intended workspace.
3. Update protected consumer configuration and run a harmless supported read.
4. Confirm the consumer uses the new key before revoking the old one.
5. Verify the revoked key is rejected in a controlled check.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Consumer: nightly lead reconciliation
Required scope: leads:read
Cutover test: GET /api/leads with replacement key
Revocation gate: consumer confirmed healthy
Final evidence: old key rejected, new key succeeds

Read the result

The overlap prevents avoidable downtime, but should have an owner and end condition. If exposure is suspected, immediate revocation may take priority over a routine no-downtime sequence.

Check before moving on

1. Check every deployment using the old secret.
2. Avoid logging either key during verification.

Limits and next action

Do not grant broader scopes merely to make the replacement test pass. A different workspace or route permission can explain the failure and should be corrected deliberately.

Source: Zintara product context