Every protected endpoint uses the same organization-scoped API key. The same bearer token authenticates create, read, regenerate, usage, and billing requests. Keys belong to organizations, not end users. Keep them in server configuration or a secret manager, never in browser code, mobile apps, or anything shipped to clients.Documentation Index
Fetch the complete documentation index at: https://docs.katalo.ai/llms.txt
Use this file to discover all available pages before exploring further.
Open API settings
Issue, rotate, and revoke organization API keys from the Katalo dashboard.
Create an API key
- Open API settings in the Katalo dashboard.
- Confirm you are in the organization that should own the integration.
- Click Issue API key or Re-issue key.
- Name the key after the integration or environment that will use it.
- Copy the raw secret immediately. It is shown once.
Store the key on the server
Use an environment variable or secret manager so the key stays out of source control and can vary by environment.Rotate or revoke keys
| Action | When to use it |
|---|---|
| Rotate | Refresh credentials, separate environments, or move an integration to a different service. |
| Revoke | Cut off access immediately if a secret was exposed or the integration is no longer in service. |
| Audit | Review key names and last-used timestamps to keep access understandable. |
Keep API keys off the client
The public API is designed for trusted server-to-server use. Browsers and mobile apps should call your backend, not Katalo directly.| Rule | Why it matters |
|---|---|
| No direct browser calls | A bearer token in browser code is a credential leak. |
| No permissive CORS strategy | Your backend should authenticate to Katalo and enforce client-level authorization. |
| One organization-scoped credential | Centralized key lifecycle is easier to rotate, review, and revoke. |