Security and Configuration

The core principles for protecting API Keys are: do not expose them, use least privilege, rotate regularly, and keep usage traceable.

How should I manage and protect API Keys?

Recommended practices:

• Do not commit API Keys to public repositories, frontend pages, mobile packages, or screenshots.
• Read API Keys from environment variables or a secrets manager on the server.
• Create separate API Keys for development, testing, and production.
• Create separate keys for different services or applications to improve traceability and isolation.
• Configure model permissions as needed, and set expiration dates where appropriate.
• Rotate API Keys regularly; rotate immediately after personnel changes, service shutdown, or suspected leakage.

If an API Key may have leaked:

1. Disable, delete, or rotate the old key immediately.
2. Create a new key and update all dependent services.
3. Review recent usage, balance changes, and abnormal spending.
4. Tighten model permissions and consider a shorter expiration.
5. Review the leakage path, such as repositories, logs, CI config, or third-party clients.

API Key leakage can cause unauthorized calls and cost loss. Even test keys should be protected like production secrets.

Can I view the full API Key again after creation?

No. The full API Key is shown only in the successful creation flow. The console displays only a masked preview afterward.

Before closing the creation dialog, store the key in a server-side environment variable or secrets manager. A lost key cannot be recovered through user or administrator APIs. Create a replacement, update the caller, and then delete the old key. The Docs AI integration template uses an <API_KEY> placeholder and does not load historical keys.

How should I send an API Key?

Send API Keys only in request headers. We recommend:

Authorization: Bearer YOUR_API_KEY

You may also use:

X-API-Key: YOUR_API_KEY

Never put an API Key in the URL query. The query names apiKey, api_key, apikey, x-api-key, and key are rejected case-insensitively with HTTP 400. They are rejected even when empty, repeated, or accompanied by a valid authentication header.

This rule does not affect ordinary business query parameters such as token for OAuth flows, apiKeyId, username, or pagination_token.