Rotating Keys

How rotation works here

There is deliberately no "rotate" button that swaps a key's secret in place. A transmute key is immutable from creation to revocation; rotation is a three-step overlap:

1. Create a new key in the portal with the same environment and scopes (you have 20 slots, so an overlap never requires deleting first).
2. Deploy the new key to your systems and confirm traffic flows (watch for 401s dropping to zero on the old key).
3. Revoke the old key in the portal.

Revocation is immediate — there is no grace period. The next request with a revoked key gets a uniform unauthorized 401. This is why the order above matters: revoke last, after the new key is verified in production.

If a key has leaked

Skip the overlap. Revoke the leaked key immediately, accept the brief outage, then create and deploy a replacement. An exposed key that can convert your payment traffic is worse than a few minutes of 401s.

Making rotations painless

• Name keys by system and generation: worker-prod-2026a, worker-prod-2026b. The portal list then tells you at a glance which key is current.
• One key per system. Rotating a shared key forces you to redeploy everything at once.
• Load the key from your secret manager at startup rather than baking it into images — then rotation is a secret update plus a restart, not a rebuild.
• Schedule it. Nothing in transmute forces rotation (portal keys never expire), so put it on your own calendar — quarterly is a common cadence for payment infrastructure.

OAuth alternative

If your security posture requires short-lived credentials as a rule, use OAuth client credentials instead of long-lived keys: tokens expire after 15 minutes, and revoking the client stops new tokens immediately (outstanding tokens live out their ≤15-minute lifetime).