Comment on page
A webhook (also called a web call back or HTTP push API) is a way for an application to provide other applications with real-time information. You can use Webhooks for more seamless integration with your other systems.
You can subscribe to webhooks so your systems are notified of events in Enate as they happen, allowing you to get data immediately. This makes webhooks much more efficient for both provider and consumer. An example might be if a new Case gets created – if this happens then Enate will send a request to your system to let you know.
It's important to be familiar with Webhooks before embarking on using them. You can check out a list of the Webhooks currently available in Enate:
APIs exist in Enate to allow you to get information about the available Webhooks and their structure, and to subscribe / update / unsubscribe from them. A quick example of this would be the API to bring back the list of all the currently available webhooks. Check out the details for this in the API Webhook Subscription section:
Make sure to check out our sample Webhook integrations section here:
This sections contains common webhook troubleshooting questions to help with any general queries you might have:
Authentication for creating or updating a Webhook subscription is the same as for any other Enate API, the user account creating the subscription must have the Process Builder role as well as permission to access data related to the requested entity (Customer, Contract etc.). Authentication is required at various points when using Webhook . There are two main places where Webhook authentication takes place:
When the Webhook subscription is created the subscriber needs to provide valid user credentials (as with any other API call) and where the subscription refers to a specific entity (i.e. events related to a Company) the account needs to have permissions on that entity.
Note: This check is also carried out when every Webhook message is being prepared in case the account's permissions have changed since the subscription was originally created).
Every Webhook subscription has a GUID which is generated by the provider when the subscription is created. This is then included in the header of all Webhook messages sent out for that subscription to give the subscriber confidence that the incoming messages are legitimate.
In addition to the above authentication points, Webhook subscriptions have an optional custom http header which can contain any key/value data the subscriber requires i.e. it could be used to include a further key generated by the subscriber which they can use to authenticate received messages.