API auth
Keiro uses organization API keys for public API requests. Send the key as an HTTP bearer token:
On this page 1 of 5
Authorization: Bearer <api-key>Console sessions authenticate the browser console; they are not API keys and must not be copied into an application.
Create a key in the console#
Owners, admins, and developers create named keys from API Keys. The full secret appears once after creation. Store it before closing the reveal because the console cannot show it again.
See API keys for ownership, staged replacement, and revocation.
Verify bearer authentication#
Make a harmless model-list request. The prompt reads the key without echoing it, and curl takes the Authorization header from stdin, so the secret stays out of the environment, the process argument list, and shell history:
printf 'Keiro API key: '
IFS= read -rs KEIRO_BEARER
printf '\n'
curl -sS https://api.keirolabs.ai/v1/models \
-H @- <<<"Authorization: Bearer $KEIRO_BEARER" | python3 -m json.toolA successful response confirms the key and base URL. It does not guarantee that every model or capability is enabled; the returned model list is account-scoped.
Use the right credential#
Use an ordinary organization API key when testing customer response shapes. Operator or diagnostic credentials are not application credentials and can expose different behavior that public clients must not depend on.
Use a separate key for each deployment or tool. Never share one key across unrelated production, development, and personal workflows.
Handle auth failures#
Support does not need the secret. Send a request ID, timestamp, endpoint, public model ID, HTTP status, and the key's non-secret name or tracking identifier.
401means the bearer token is missing, invalid, expired, or revoked.403means authentication succeeded but the key or organization is not allowed to perform the operation.- A missing model from
GET /v1/modelsis an access or policy issue, not a reason to use an internal model name.