Authentication
Interactive Redgold clients use an account session. API clients use an sk-rg- key. Both credentials are sent as bearer tokens, but their lifecycle differs.
API keys
Create a key from the API-key page in the signed-in web application. The complete value is shown once. Store it in a secret manager or environment variable and revoke it when it is no longer needed.
export REDGOLD_API_KEY=sk-rg-...
curl https://api.redgold.ai/v1/models \
-H "Authorization: Bearer $REDGOLD_API_KEY"
Send the key in the Authorization: Bearer header. The model API reads the credential only from that header (and, for the signed-in web application, the session cookie); it does not read an X-Api-Key header, so a request that supplies the key only as X-Api-Key is rejected with 401.
Account sessions
The web application establishes an account session during sign-in and uses it for interactive requests. Treat the session as a user credential. Do not copy it into source code or use it as a long-lived CI secret.
Some account-management operations, including minting a new API key, require an account session and do not accept an existing API key as authority to create another key.
Credential handling
- Keep keys out of repositories, prompts, logs, and screenshots.
- Give each automation context its own key so it can be revoked independently.
- Use the lowest practical request limit for unattended clients.
- Replace a key if its value may have been exposed.
Authentication failures
A missing, malformed, revoked, or unknown key returns 401. An account out of model-API credits returns 402. On the data API a valid identity without permission for an operation returns 403; the model endpoints do not emit 403. Model endpoints return the error envelope matching their OpenAI or Anthropic request shape.