You can connect multiple events to each webhook. The "Add Events" button will take the trigger and events and add them to the webhook. For example, combining "Account" as the Trigger with "Update" as the event will result in the webhook triggering on any Account Update. The events listed here combine with the defined trigger. The "Triggers" drop-down allows you to define the event categories that will trigger the webhook action. The enabled checkbox will allow you to activate or deactivate the particular webhook.
The URL entered here is the recipient of the webhook, and will usually be given to you by your service provider. The name of the webhook being created will go here - this should be indicative of both the Trigger Events and the linked service for easier management in the future. This section will elaborate on those required fields, and what they mean: 1. When creating a webhook, there are several fields to fill out in order to complete the event connection. Therefore, if it is important that you receive webhooks in order, you should store the created_at value for the last event of a specific type for a specific entity so that you can deal with any out-of-order broadcasts. Because Sonar will retry webhooks over a 4 hour period, it is possible that you can receive webhooks out of order if one fails, but the next succeeds before the retry cycle on the failed item.
It may be necessary to open the Event History sidebar and view the payload in order to gather exact details.įinally, created_at is a UTC timestamp showing when the webhook was entered into Sonar for delivery. The "current" array generally contains some data about the event that may be useful for you in order to process the webhook. The "current" array may or may not contain data, but each array is detailed in this format. For example, in, the top-level entity is account, so object_id will be the ID of the account. The object ID will be the ID of the top-level entity referenced in the event. For example, an account changing status is account.status an account having a new service added is. The event name will correspond to the event registered in Sonar.
The format of POSTed webhook data is JSON and is as follows: After 4 hours have passed, all super admins registered in Sonar will receive an email letting them know a webhook is failing. The data returned is not relevant (or stored) but if the endpoint does not return an " HTTP 200" response code, Sonar will continue to POST to the endpoint once per minute for 4 hours. When Sonar POSTs a webhook to an endpoint, it expects to receive an " HTTP 200" response code. The web server receiving the webhook MUST support both the HTTP HEAD and POST methods. The endpoint you enter when configuring a webhook is the location Sonar will POST data to, and you select from the list of webhook events to determine which webhooks are posted to the specified endpoint. When creating a webhook, you need to select an endpoint. In this article, the functionality of webhooks in Sonar will be explored, and examples surrounding the usage of webhooks to enhance your experience within Sonar. While the API can be used to trigger certain actions within the instance (such as creating a serviceable address), a webhook is specialized in triggering an action outside of Sonar (such as automatically sending a letter to a customer through some 3rd party service when their account is created). Webhooks serve a kind of inverse functionality to the API. If you've been using Sonar and exploring the various features we offer, you'll likely have encountered the different articles provided in the knowledge base describing the usage of Sonar's GraphQL API integration to manage the data being entered into Sonar.