Authentication & keys

Every /v1 request carries a per-user secret key (sk-...) via either header:

Authorization: Bearer sk-...

or

X-API-Key: sk-...

Creating keys

Create and manage keys in the lab under the API Keys tab: ai.klikg.com/lab.

• The full secret is shown exactly once at creation time. Only a masked form (sk-ab****cdef) is retrievable afterwards - if you lose a secret, revoke the key and create a new one.
• Each user can hold up to 20 non-revoked keys.
• Keys can be renamed, disabled/re-enabled, and permanently revoked from the same tab.

Per-key limits

Each key has four editable limits. Blank means unlimited (still subject to the user's TIK balance, which is enforced separately).

Limit	Enforced when
Jobs / day	On job submission. Resets at 00:00 UTC.
Jobs / month	On job submission. Resets on the 1st of each month (UTC).
Max concurrent jobs	On job submission, against currently running jobs for the key.
TIK / month	On job submission, against TIK spent through this key this month.

A submission over a limit is rejected with 429:

{ "error": "Rate limit exceeded", "reason": "limit_exceeded", "limit": "jobsPerDay" }

Only job submissions (POST /v1/generate) count against quotas. Status polls, event streams, and file downloads never consume quota, and neither do submissions rejected during a cold start (503).

Key lifecycle

State	Behavior
active	Works normally.
disabled	All requests rejected with 401 (reason: "disabled"). Reversible from the lab.
revoked	All requests rejected with 401 (reason: "revoked"). Permanent.

Security notes

• Treat keys like passwords: server-side only, never in client-side code or public repositories.
• The platform stores only a SHA-256 hash of each secret.
• Usage (jobs today / this month, TIK spent) is visible per key in the lab, so one key per integration makes attribution and revocation clean.