How to Create API Keys and Read Data with the KC Safety Public REST API

Summary

The KC Safety public REST API lets another system read your safety data over HTTPS on its own schedule. You create an API key in the Admin Panel, pass it as a bearer token, and call the available read endpoints for incidents, incident types, users, locations, and departments. Where webhooks push events to you, the API lets you pull data when you need it.

Introduction

Some integrations do not fit an event model. A nightly report, a data warehouse load, a lookup from an internal tool, or a dashboard that refreshes on demand all need to ask KC Safety for data rather than wait for something to happen.

The public REST API covers that case. An external system authenticates with an API key scoped to your account and reads KC Safety records over HTTPS. Requests are rate-limited per plan and always scoped to your own account's data.

You will need the Super Admin role to create and manage API keys.

Key Concepts

• API key — a credential that identifies and authorizes an external system calling the API on behalf of your account. Keys begin with the prefix kcs_.
• Bearer token — how the key travels on each request, in the Authorization header.
• Scope — the permission level recorded on a key: read, read-write, or admin.
• Rate limit — the cap on how many requests a key may make in a given period, determined by your plan.
• Account scoping — every response contains only your own account's records; a key cannot reach another account's data.

Steps to Follow

Step 1: Open the API Keys settings

Sign in as a Super Admin and go to Admin Panel → Settings → Integrations → API Keys.

Step 2: Create a key and store it immediately

Create a key, then copy it straight away and store it in your secrets manager.

Note: The raw key — the value beginning kcs_ — is displayed only once, at creation. KC Safety stores only a hash of it, so the value cannot be shown again afterwards. If you lose a key, revoke it and create a replacement.

Step 3: Authenticate your requests

Pass the key as a bearer token on every request:

curl -H "Authorization: Bearer kcs_xxxxxxxx" \
  "{safety_base_url}/api/v1/public/incidents"

Replace {safety_base_url} with your KC Safety base URL and kcs_xxxxxxxx with your key. Send requests over HTTPS only, and never embed a key in client-side code, a browser request, or a public repository.

Step 4: Call the available read endpoints

These read endpoints are available today:

Step 5: Work within your rate limit

Requests are rate-limited according to your plan. Design your integration to read incrementally and cache what it can rather than re-reading the full data set on a tight loop. If you need to react to changes promptly, use outbound event webhooks instead of polling the API — webhooks deliver the event within seconds and consume no API quota.

Step 6: Revoke keys you no longer need

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

Note: The public API is read-only today. It exposes only GET endpoints. The read-write and admin scopes exist in the key model, but there are no write endpoints, so a key cannot create or modify KC Safety data through the public API regardless of the scope recorded on it. Treat this as a reporting and read-integration API. To get data into KC Safety from outside, use inbound email reporting for incidents or SCIM provisioning for user accounts.

Conclusion

The public REST API is the right tool when another system needs to read KC Safety data on its own schedule. Create a dedicated key per integration, copy it at creation because it is shown only once, send it as a bearer token over HTTPS, and revoke keys that are no longer in use. Because the API is read-only, pair it with outbound webhooks when you also need to react to events as they happen, and use inbound email or SCIM when you need to send data into KC Safety.