> Keiro Labs API documentation - API Keys > Page: https://docs.keirolabs.ai/api-keys.html > Markdown: https://docs.keirolabs.ai/api-keys.md > Agent index: https://docs.keirolabs.ai/llms.txt > API base URL: https://api.keirolabs.ai/v1 > Auth: send "Authorization: Bearer " with a key created in the > Keiro console (https://console.keirolabs.ai/api-keys). Use credentials saved by > `keiro setup`, or resolve the key from a secret manager or an owner-only > secret file and pass it to the client explicitly. Never read another > provider's variable, and never put raw key material in environment > variables, code, docs, or logs. # API keys Create and manage organization API keys in the [Keiro console](https://console.keirolabs.ai/api-keys). API keys authenticate requests to the public API; console sessions and API keys are separate credentials. ## 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 ``` For the Keiro Python package, use the saved-credential bootstrap in [SDKs](sdks.md); it stores credential metadata separately from owner-only secret files. For terminal coding agents, follow the key handling in [Codex](codex.md) or [Claude Code](claude-code.md). For raw HTTP and OpenAI-compatible SDK examples, follow the credential handling in [Quickstart](quickstart.md) and [SDKs](sdks.md). ## 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: 1. Create a new key for the same workload. 2. Save the new secret in the workload's approved secret store. 3. Deploy or reload the workload with the new key. 4. Verify a harmless `GET /v1/models` request or a normal application request succeeds with the replacement. 5. In the console, delete the old key. 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. ## 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: - 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 Support never needs the full secret. Send the key name or non-secret tracking identifier, request ID, timestamp, and HTTP status instead. ## Related pages - [API auth](api-auth.md) - [Usage and billing](usage-billing.md) - [Rate and spend limits](rate-and-spend-limits.md) - [Status and support](status-support.md)