Introduction
Webhooks are how services notify each other of events. At their core, they are just a POST request to a pre-determined endpoint. For example, when a data API object has been successfully processed (workflow.succeeded), SafetyKit will send a POST request to the endpoint you’ve configured on your system.
The endpoint can be whatever you want, and you can configure them from the SafetyKit UI. It’s typical to use a separate endpoint for every service. For example, the endpoint for receiving events from SafetyKit could be https://www.example.com/safetykit/webhooks/.
Your endpoint should indicate that the event from SafetyKit has been successfully processed by returning a 2xx (status code 200-299) response within a reasonable time-frame (within 15 seconds with SafetyKit). It’s also important to disable CSRF protection for this endpoint if the framework you use enables them by default.
Another important aspect of handling webhooks is to verify the signature and timestamp when processing them in order to be sure the request actually originated from SafetyKit. You can learn more about verifying webhook signatures.
SafetyKit also supports webhook redelivery for specific scenarios, such as reprocessing batches of objects or events within a particular timeframe. If you need webhooks resent, please contact our support team to coordinate the redelivery process.
Event Types
Section titled “Event Types”These are the current webhook event types that SafetyKit will emit to your configured webhook endpoint: