Skip to content
Market Monolith

API-key security and lifecycle

Store secrets safely, inspect key metadata and replace or revoke a key.

On this page

Treat each application key as a secret belonging to its account-owned application. Give keys recognizable names without putting private data in their labels.

Save the secret once

Verified signup prepares the first Default key for a new developer. Returning to the console or signing in again does not create another key. A short context picker is used only when multiple eligible accounts or applications make the destination ambiguous.

The creation response is the only time the secret is shown. Store it in a trusted server secret manager or controlled local environment. It is not retrievable later from the key list, activity history or support.

If creation succeeded but the response was lost, recover the key's safe metadata. Replace it to receive a new secret; do not expect idempotency replay to reveal the original plaintext.

Replace or revoke

Creation, renaming, replacement and revocation require email proof from the last fifteen minutes and current account authority. Viewing safe key metadata does not require a fresh code while the ordinary developer session remains valid. Starting step-up must not silently replace a key or revoke an existing one.

The approved replacement contract has no overlap period: creating the replacement immediately revokes the old key. Coordinate dependent applications before replacement. A failed transaction must not leave you with an unusable half-replacement.

Revocation is irreversible. A timeout is an unknown result, not confirmation; refresh safe key status before retrying the same administrative intent.

Protect requests

Never place the secret in a URL, source repository, frontend bundle, screenshot, chat or analytics payload. Disable HTTP debug output that prints headers. Do not follow redirects while forwarding the credential to a different host.

Review access

The initial scope is authentication only. A saved key, an active badge or a successful check cannot authorize paid work. Account administrators should review names, status and last-use metadata without exposing secrets.