Expiring API keys: Sume key metadata and rotation habits

OpenAI's changelog says that on Sep 10, 2026 administrators can enforce maximum key lifetimes at the organization or project level. The Sume docs describe no expiration field, so on Sume you rotate on a schedule you keep yourself: create a replacement key, deploy it, verify with GET /v1/me, then revoke the old key.

What each side documents

The OpenAI column is from its API changelog; the Sume column is from the authentication docs.

A rotation routine for Sume keys

Sume says to create a replacement key, deploy it to your server, verify GET /v1/me, then revoke the old key from the dashboard, and to rotate if a key appears in logs or chat history. Because scopes cannot be added to an existing key, rotating is also how you pick up a scope that did not exist when the key was made, such as formats:write or actions:write.

Send exactly one credential. A request carrying both an Authorization Bearer header and x-api-key is rejected with 401, so strip the one your gateway adds before you switch keys.

# 1. Verify the new key before you revoke the old one
curl https://api.sume.com/v1/me \
  -H "Authorization: Bearer $NEW_SUME_API_KEY"

# 2. Revoke the old key in the dashboard once traffic is on the new one

Use last-used time as a check

The dashboard shows when each key was last used. After a deploy, the old key's last-used time should stop moving; if it does not, something is still calling with it, and revoking it would break that caller. Wait for the time to settle before you revoke.

• Name keys by service and rotation date so the list stays readable.
• Keep keys on servers and in CI secret stores, never in frontend code.
• Rotate on a fixed calendar, since there is no expiry to force it.
• A scope that is missing returns 403 insufficient_scope; the fix is a new key.