Skip to main content
API keys never expire, so replacing a secret is a job you schedule. This page is for whoever owns the services that hold OpenType keys: it compares the two ways to replace a secret, gives the exact calls for each, and covers what goes wrong. Pick overlap for planned rotation with zero downtime, and rotate in place when a secret has leaked and must stop working now.

Pick a pattern

Both patterns need a credential with keys_write, and listing keys needs keys_read. In the examples on this page, OPENTYPE_API_KEY holds that management key, not the runtime key you are replacing. Only the key’s id goes in a URL; the secret never does.

Overlap: rotate without downtime

1

Find the key you are replacing

List your keys and note the id, name and scopes of the one to replace. secret_prefix (the first 13 characters of the secret) tells you which deployment holds it.
2

Create the replacement

Create a new key with the scopes the service needs. You can only grant scopes you hold yourself. The response is the only time the secret is shown.
3

Store it and deploy

Write the secret into your secret store and roll it out to every instance of the service.
4

Confirm the old key is idle

Read the old key and check that last_used_at has stopped moving. It is updated in the background, about once a minute at most, so wait a few minutes after the last instance restarts.
5

Revoke the old key

DELETE /v1/keys/{key_id} with the old id. The old secret stops authenticating on its next request. The row stays listed with state: "revoked" for audit.
The whole flow, as a script:

Rotate in place: when a secret leaks

POST /v1/keys/{key_id}/rotate issues a new secret for the same key. The id, name and scopes stay the same. The old secret stops working at once, so every caller still holding it gets 401 invalid_credential until it has the new one. That is what you want when a secret has leaked.
The response has the same fields as a newly created key: the key record plus secret, returned with 200. secret_prefix changes to match the new secret. No field records the rotation time.
If a secret was ever sent in a URL path, the API answers 400 secret_in_path and does nothing else. Treat that secret as leaked: rotate it right away, then call the route again with the key_ id.

After a leak

  1. Rotate the key, or revoke it if nothing legitimate uses it.
  2. Deploy the new secret to the callers that should have it.
  3. Read usage reporting for the window of the exposure and check for runs you do not recognize.

What the old secret does after each action

A revoked key cannot be rotated or re-enabled. To replace it, create a new key.

Errors

Plan it

  • Give every environment and service its own key, so rotating one never touches the others. Name keys after the process that holds them.
  • Keep a management key apart from runtime keys. A runtime key needs runs_write and runs_read; only the key that performs rotation needs keys_read and keys_write.
  • Rotate on a schedule you choose, since keys never expire, and after anyone with access to a secret leaves.
  • Revoke keys that stop being used. last_used_at shows which ones.