Authentication

The KC Safety Public REST API authenticates every request with an API key sent as a bearer token. There is no OAuth flow and no token exchange step.

Authorization: Bearer kcs_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Keys are prefixed kcs_ followed by 40 hexadecimal characters. The header must begin exactly with Bearer kcs_ — there is no alternative header such as X-API-Key.
The key both authenticates the caller and resolves the account. Every response is automatically scoped to the key's account, so there is no account or tenant parameter to pass, and a key can never reach another account's data.
The raw key is displayed once, at creation. Only a hash is stored, so the value cannot be retrieved again. If a key is lost, revoke it and create a replacement.

Send requests over HTTPS only. Never embed a key in client-side code, a browser request, or a public repository.

Example request

curl -H "Authorization: Bearer kcs_xxxx" \
  "https://safety-api.knowledgecity.com/api/v1/public/incidents?page=1&limit=50"

Scopes

Each key carries a scope: read, read-write, or admin. The scope governs which HTTP methods the key may use — read permits GET; read-write and admin additionally permit write verbs.

Because this API is read-only today, scope has no practical effect on the current surface: a read key can reach every endpoint. Scopes exist for forward compatibility with future write endpoints. Choose read unless you have a specific reason not to.

Managing keys

Keys are managed by a tenant administrator at Admin Panel → Settings → Integrations → API Keys, which requires the Super Admin role and a plan that includes API access.

Create — name the key and optionally set a scope (default read) and an expiry date. The raw kcs_ value is shown once; copy it immediately.
List — shows each key's name, prefix, scope, active state, last use, and expiry. The raw value is never shown again.
Rename, enable or disable, change scope — all supported.
Revoke — immediate and permanent. Requests using a revoked key return 401 API_KEY_INVALID.

Issue a separate key per integration, so revoking one does not interrupt the others. Revoke any key that is unused, has been exposed, or belonged to a decommissioned system.

See also Errors for what an authentication failure looks like on the wire.