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 RequestBeam API credentials in the URL query. Credential-style names (apiKey, api_key, apikey, x-api-key and key) normally trigger HTTP 400. Narrow Similarweb business-parameter exceptions apply to GET requests only: /v1/similarweb/websites/backlinks accepts one uppercase Key hostname; /v1/similarweb/websites/outgoing-traffic, /websites/incoming-referrals and /websites/similar-sites/suggestions accept one lowercase key hostname (all under /v1/similarweb). These fields identify a target website, not an API credential. Hostnames must be valid. Duplicates, wrong casing, credential-like values and extra credential query fields remain blocked. Always authenticate with a request header, including on Similarweb routes. See the Similarweb request example.

This rule does not affect other business parameters such as OAuth token, apiKeyId, username or pagination_token.