API keys

Create and manage organization API keys in the Keiro console. API keys authenticate requests to the public API; console sessions and API keys are separate credentials.

On this page 1 of 7

Create a key#

To create API key credentials, organization owners, admins, and developers use the console. Give each key a name that identifies one workload or deployment, such as production-api or codex-jane-laptop.

The console shows the full secret once, immediately after creation. Copy it to an approved local credential store or secret manager before closing the reveal. The console cannot recover the secret later.

Use separate keys for separate workloads so usage is attributable and one compromise can be contained without disrupting unrelated traffic.

Authenticate a request#

Send the secret as a bearer token:

Text

Authorization: Bearer <api-key>

For the Keiro Python package, use the saved-credential bootstrap in SDKs; it stores credential metadata separately from owner-only secret files. For terminal coding agents, follow the key handling in Codex or Claude Code. For raw HTTP and OpenAI-compatible SDK examples, follow the credential handling in Quickstart and SDKs.

Protect your API key#

For local development, keep the secret in a password manager, your OS credential store, or an owner-only file, and read it at the moment of use. Do not export it from a shell profile or a shared .env file — a profile export puts the secret in a file at rest and into the environment of every process you start. keiro setup does this handling for you; the examples in these docs prompt for the key instead (getpass in Python, the Keiro API key: prompt in curl).

For CI and production, do not use shell profiles or checked-in environment files. Inject the key at runtime from your platform's secret manager, and pass it to the SDK constructor explicitly. Configure clients to fail fast when the variable is missing rather than falling back to another provider's credential.

Rotate without an avoidable outage#

The customer console uses staged replacement for rotation:

Deleting a key revokes it immediately; new requests using it stop authenticating. Keep the overlap only as long as verification requires.

If a key may already be exposed, delete it first, replace it, and contact support if you need usage or billing review. Do not leave a suspected key active to preserve an overlap window.

Create a new key for the same workload.
Save the new secret in the workload's approved secret store.
Deploy or reload the workload with the new key.
Verify a harmless GET /v1/models request or a normal application request succeeds with the replacement.
In the console, delete the old key.

Review key state#

The API Keys page shows non-secret identity, status, creation time, creator, last-use time, and applicable restrictions. Individual keys can have narrower model, streaming, rate, concurrency, or spend access than the organization. A key cannot raise its organization's limits.

Use the Usage page to filter activity by key. A key with no recent activity may still be deployed in an infrequent workload, so confirm ownership before revoking it.

Keep keys out of unsafe channels#

Never put a key in:

Support never needs the full secret. Send the key name or non-secret tracking identifier, request ID, timestamp, and HTTP status instead.

source code or a repository
shared .env files
URLs or query strings
shell command arguments or copied command history
logs, screenshots, tickets, chat, or email
public docs or example payloads