Webhooks are a way for your in-house system to receive notifications of events or actions happening in Salv. Whenever a specified event happens in Salv either due to a human operator making a change or for some automatic system activity, Salv can send a signal to your system with a webhook, which you can use to make further decisions or perform some extra automatic or manual activity.
List of available webhooks
The following events are currently available in the webhooks system:
ALERT_CREATED (trigger: ALERT) - Salv system generated a transaction or person monitoring alert.
ALERT_STATUS_UPDATED (trigger: ALERT_STATUS) - A human operator or some automatic process changed the status of transaction or person monitoring alert.
SCREENING_ALERT_CREATED (trigger: SCREENING_ALERT) - Salv system generated a screening (PEP, sanctions, adverse media, Custom list) alert.
💡 It's important to observe the alert status on this webhook. Status FILTERED means that it is an automatically resolved alert and you will probably never receive a follow up SCREENING_ALERT_STATUS_UPDATED event. Status NEW on the other hand means that this alert needs manual resolution and therefore you can expect a future SCREENING_ALERT_STATUS_UPDATED event.
SCREENING_ALERT_STATUS_UPDATED (trigger: SCREENING_ALERT_STATUS) - A human operator or some automatic process changed the status of screening alert.
PERSON_STATUS_UPDATED (trigger: PERSON_STATUS) - A human operator changes the status of a customer in Salv.
FINAL_RISK_UPDATED (trigger: FINAL_RISK) - This refers to when a person’s new final risk level was previously different, or where a (new) person is risk scored after being added to Salv.
CUSTOM_LIST_RECORD_CREATED (trigger: CUSTOM_LIST_RECORD) - Custom list record was created, either via UI or API.
CUSTOM_LIST_RECORD_UPDATED (trigger: CUSTOM_LIST_RECORD) - Custom list record was updated, either via UI or API.
CUSTOM_LIST_RECORD_ARCHIVED (trigger: CUSTOM_LIST_RECORD) - Custom list record was archived, either via UI or API.
PERSON_CHECKS_RESOLVED (trigger: PERSON):
Decision rule conditions were met. Decision rules can be customised to automate processes.
Default Decision rule is set to send a webhook when the last active screening or real-time monitoring alert has been resolved for a specific person.
TRANSACTION_CHECKS_RESOLVED (trigger: TRANSACTION):
Decision rule conditions were met. Decision rules can be customised to automate processes.
Default Decision rule is set to send a webhook when the last active screening or real-time monitoring alert has been resolved for specific transaction.
💡 Check API documentation for payload description here.
How to add and manage webhooks
To work with webhooks, navigate to Settings. You can add webhooks here, as well as review your existing webhooks.
To add a webhook, just click the “Add new webhook” button, and a form shows up. Fill the link of your HTTP endpoint, select the trigger that you are interested in, and click Save.
🔑 Provide optional secret value in Authentication token field that will be passed with every webhook request in X-Salv-Token header. You can use it to verify authenticity of the request.
How webhooks work
Webhooks are implemented as HTTP requests from Salv servers to your system. When creating a webhook, you need to specify the HTTP endpoint on your side, as well as the trigger that you are interested in.
When event happens, Salv sends a request to your system to the specified endpoint, including the metadata that is relevant for the event. For example, here is the info that you receive as part of the PERSON_STATUS webhook notification:
As you see, the info contains the ID of the customer in the Salv system, the previous and new statuses, as well as the name of User who updated the status. You could extract this info to use it for further processing, perhaps by querying more info from Salv using the REST API, or using this info for your internal processes.
Troubleshooting webhook requests
One can find failed webhook requests with reason for failure under Settings > Webhooks tab under webhooks list.
🔍 You can access failed requests for up to 6 months and all other request data for up to 3 months.
