Setting Up

API keys

Create, store, rotate, and revoke the organization-scoped credential used by every protected endpoint.

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.

Send the key as Authorization: Bearer kat_live_<publicKeyId>.<secret> on every authenticated request.

Create an API key

Create one organization-scoped key in the dashboard, give it an integration-specific name, and copy the raw secret immediately.

Open the API settings page

Navigate to the organization API settingsand confirm that API access is enabled for the current organization.

Issue the key

Click Issue API key, name it after the integration or environment that will use it, and store it in the backend service that calls Katalo.

Copy the secret immediately

The raw secret is shown once. If you lose it, issue a new key instead of expecting 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 the environment in application code:

import os

api_key = os.environ["KATALO_API_KEY"]

Best practice

Treat the API key like any other backend secret. Restrict which services can read it, rotate it if exposure is possible, and do not reuse the same credential across unrelated environments.

Rotate or revoke keys

Rotation gives you a new secret. Revocation disables the old one immediately.

Rotate a key

Issue a replacement key when you need to refresh credentials, separate environments, or move an integration to a different service.

Revoke a key

Revoke a key to cut off access immediately if a secret was exposed or the integration is no longer in service.

Audit access

Use the dashboard metadata, including key name and last-used timestamps, to keep access reviewable.

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.

Public API overview

Generations

API keys

Выберите, как Katalo использует cookie