API Keys
API keys are issued under a workspace and authorize every gateway call. Treat them like passwords.
Create a key
- Open Workspace → API Keys.
- Click Create / New key.
- Give it a clear name (for example
local-dev,staging,prod-backend). - Copy the secret once and store it in your secret manager or environment variables.
export APIGO_API_KEY=sk-apigo-...
Use it as a Bearer token:
Authorization: Bearer sk-apigo-...
Recommended practices
- One key per environment or service — never share a production key with local laptops.
- Prefer server-side calls. Do not ship keys in browser bundles or mobile apps.
- Set day / 7-day / 30-day spend caps, RPM, TPM, and concurrency limits where appropriate.
- Pause or revoke keys immediately when a service is retired or a secret leaks.
- Bind high-risk keys to a Routing policy so fallbacks and model scope stay explicit.
Limits and defaults
Workspace managers can configure default limits that are copied into new keys. Changing the template does not update existing keys.
API key and Workspace runtime layers are enforced independently. An unset or 0 key runtime value disables only the key-specific layer; it never bypasses a positive Workspace hard limit.
Read Limits and request enforcement for the full value precedence, spend windows, shared Workspace behavior, and error codes.
Debugging auth failures
| Symptom | Check |
|---|---|
401 invalid_api_key |
Typo in Bearer header; key paused/revoked; wrong workspace |
| Works in Chat but not in SDK | SDK still pointing at another provider base URL |
| Works for one teammate only | They may be using a different workspace or key |
After each failed auth attempt, keep the X-Request-Id (when returned) and look up the request under Call Logs.
