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.
Authorization : Bearer kat_live_<publicKeyId>.<secret>
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.
If you lose the raw secret, issue a new key. Do not expect to recover the old value.
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.
export KATALO_API_KEY = "your-api-key-here"
Read it from application code:
import os api_key = os.environ[ "KATALO_API_KEY" ]
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.
