Summary
KC Safety connects to other systems through several independent integration surfaces: outbound event webhooks, a read-only public REST API, inbound email reporting, a custom-workflow webhook action, the KC LMS training integration, and enterprise single sign-on with SCIM provisioning. This article explains what each surface does, which direction data flows, and where it is configured, so you can choose the right one for your use case.
Introduction
Most organizations run KC Safety alongside other systems — an HR platform, a service desk, a data warehouse, or a custom internal tool. Those systems often need to know when something happens in KC Safety, or need to read safety data on their own schedule.
"Integrations" in KC Safety is an umbrella over several independent mechanisms rather than a single connector. Each one solves a different problem: pushing events out the moment they happen, letting another system pull data on demand, accepting reports from outside the product, or keeping user accounts in step with your identity provider.
Most integrations are configured per account under Admin Panel → Settings → Integrations, which requires the Super Admin role. Inbound email reporting is configured under Settings → General, and the workflow webhook action under Settings → Workflows.
Key Concepts
- Outbound event webhooks — KC Safety sends an HTTP request to a URL you own whenever a subscribed event occurs, so another system can react in near real time.
- Public REST API and API keys — another system authenticates with a bearer API key and reads KC Safety data over HTTPS on its own schedule.
- Push versus pull — webhooks push an event to you as it happens; the API lets your system pull data when it wants it. Many integrations use both.
- LMS / training integration — an outbound connection to the KC Learning Platform that pushes training enrollments and mirrors course and learner data back.
- Inbound email reporting — an email sent to a designated address becomes a new incident, without the reporter needing to sign in.
- SSO and SCIM provisioning — enterprise single sign-on from your identity provider, plus automated creation, update, and deactivation of user accounts.
Steps to Follow
Reviewing the available integration surfaces
Use this table to identify which surface fits your requirement, then follow the dedicated article for that surface.
| Surface | Direction | What it is for | Where configured |
|---|---|---|---|
| Outbound event webhooks | KC Safety → your system | Push events such as incident created or status changed to a URL you own, so another product can react in real time. | Settings → Integrations → Webhooks |
| Public REST API and API keys | Your system → KC Safety | Let another product read incidents, users, locations, and related records using a bearer API key. Read-only today. | Settings → Integrations → API Keys |
| LMS / training integration | KC Safety → KC LMS | Push training enrollments to the KC Learning Platform and mirror course and learner data back. | Settings → Integrations → LMS Integration |
| Inbound email reporting | Email → KC Safety | Turn a forwarded or parsed email into a new incident automatically. | Settings → General → Email-in Reporting |
| SSO and SCIM provisioning | Identity provider → KC Safety | Enterprise single sign-on and automated user provisioning and de-provisioning. | Settings → Integrations → SSO & SCIM |
| Custom-workflow webhook action | KC Safety → your system | Fire a one-off webhook from a specific workflow transition, without registering a global endpoint. | Settings → Workflows |
Choosing between pushing and pulling data
If your goal is for another system to react to something happening in KC Safety — opening a ticket when an incident is reported, posting to an internal dashboard, starting an approval — use outbound event webhooks. Delivery happens within seconds of the event, and you do not have to poll.
If your goal is for another system to read KC Safety data — a nightly report, a data warehouse load, a lookup from an internal tool — use the public REST API with an API key. This is the right choice when you need data on your own schedule, or need records that no event covers.
If your goal is to get data into KC Safety from outside, use inbound email reporting for incident intake, or SCIM provisioning for user accounts. The public REST API is read-only, so it cannot be used to create or modify records.
Opening the Integrations settings
Sign in as a Super Admin, open the Admin Panel, and go to Settings → Integrations. Each surface has its own pane: Webhooks, API Keys, LMS Integration, and SSO & SCIM. Changes apply to your account only.
Note: Single sign-on and SCIM provisioning are handled through KnowledgeCity User Directory rather than natively within KC Safety. Follow the platform SSO and SCIM documentation for those, and treat the KC Safety pane as the place where the connection is enabled for this product.
Conclusion
KC Safety offers a small set of well-defined integration surfaces rather than one general-purpose connector, and picking the right one is most of the work. Use outbound webhooks when another system needs to react to events as they happen, the public REST API when a system needs to read data on its own schedule, inbound email for report intake, and SSO with SCIM to keep user accounts aligned with your identity provider. Each surface has a dedicated article in this section with full setup steps.