The POST method on the resource group can be used to create a new screening webhook. This will automatically generate a webhook key and unique ID for the new webhook. The response payload will contain both the unique ID and the newly generated webhook key which should be stored in a vault or secrets manager for the receiving service to authenticate the request via the “x-webhook-key” header. The webhook key will also be present on any GET requests for the webhooks so it is possible to retrieve the webhook key again in the future.
Notice: each tenant is allowed a maximum of 10 webhooks by default. More webhooks are available for enterprise customers upon request. If the maximum for the tenant has been reached, consider reviewing the existing webhooks and deleting un-used webhooks using the Delete Screening Webhook method.
Admin API key for authentication
Request body for creating a new screening webhook
The name that should be assigned to the webhook. This is for reference purposes, and will be echoed back in the webhook payload together with the webhook unique ID. It can be helpful to assign a system reference ID or other reference code. It can also be used to identify different webhooks as dev vs prod, or by purpose.
"Test webhook"
The list of events that the webhook should subscribe to. If more than one event is provided, it is treated as an OR gate where if any of the conditions in the events of the array are applicable, the webhook will trigger. At least one event must be provided.
The URL that the webhook should POST to when event conditions are met
"https://your.web.site/path"