Refresh an API key
Atomically revoke an existing API key and issue a replacement with the same metadata (name, description, and key type).
The old key is invalidated and the new key is activated in a single transaction — there is no window where neither key is valid. The full new key value (key) is only returned once in the response. Store it securely.
Authorization:
- User keys: The creator or an account admin may refresh the key.
- Service keys: space admins (and higher) may refresh any service key in their space. Non-admins require the SERVICE_KEY_CREATE permission and must be the creator of the key.
Expiry behaviour: expires_at is required when the existing key has an expiry — omitting it would extend the key's lifetime to unbounded and is rejected with 422. For unbounded existing keys, expires_at may be omitted (the replacement is also unbounded) or supplied to add a specific expiry. The value must not be later than the existing key's expiry; to issue a key with a longer lifetime, use POST /v2/api-keys.
Grace period: Supply grace_period_seconds in the request body to keep the old key valid for that many seconds after the refresh. If not supplied, the old key is revoked immediately.
<Note>This endpoint is in beta, read more here.</Note>
Path parameters
A universally unique identifier (base64-encoded opaque string).
The unique API key identifier (base64)
Request body
Example request
{
"expires_at": "2027-01-01T00:00:00Z",
"grace_period_seconds": 300
}Response
Refreshed API key. The raw replacement key is only returned once.