Introducing our Webhook feature for the Engagement Builder

We have added two new features to the Engagement Builder:

1. The Engagement Builder which can be triggered by an inbound Webhook (aka custom event received)
2. The Engagement Builder that can send out a webhook (aka.outbound webhook)

What is a webhook and what does it mean in the context of the Engagement Builder?

A webhook is an automated message sent from apps when something happens. For example, when a potential buyer submits a form, the customer can automatically send us the form data (e.g. name, address, phone number, etc) as a Webhook and this Webhook can trigger the Engagement Builder to do something (e.g. send an email). This represents a case of an inbound Webhook that triggers the Engagement Builder.

On the other hand, we can send an outbound Webhook using the Engagement Builder as well. For example, if we have received the potential buyer’s name, email address, and interest in finance via a form, the Engagement Builder can automatically send all this data to your CRM system as a Webhook. You can trigger webhooks on other criteria, like the end of a phone call, in order to receive call data in a dedicated endpoint (or multiple endpoints per call). 

Our Inbound and Outbound webhook features are designed in a generic way, which means that you can send us any data and receive any data that you want, which means there is great potential for applying various use cases. 

Sending a webhook

You can start by building a new workflow in our Engagement Builder solution:

With a new workflow on the way, you can select the criteria you need first before our system sends a webhook out to your endpoint. There are multiple options to choose from so use the one that fits your use case best. For more details you can read about criteria here. 

Once you have selected the right criteria for you, for example A Call Ends for answered calls, you can then start adding the details for your webhook in the Delivery Method section. First select "Send a webhook" in the Delivery Method drop menu, and start adding other details such as the endpoint, authentication if any, or the contents of the payload. 

Note: You can even add a delay so the webhook is not sent out immediately after the call ends (or the criteria selected in the previous step is met) and you can instead receive the payload in your end minutes, hours or even days later. More on delays here. 

Once things are set up, it may look something like this:

• Endpoint: Add your endpoint url here to receive data from Kaisa. Please note you can add multiple endpoints if you want to receive the same payload in different systems or endpoints for each call or event.
• Authentication: You can choose to authenticate your webhook using different systems, such as an authentication header (adding a Bearer Token) or setting up an OAuth2 authentication in Settings. You can also chose among set up integrations like Salesforce. 
• POST request body: add your payload here, using the right format for the option selected under the Body box (url encoded or JSON)

Once it's all ready you can activate the workflow to start receiving this data in your end. 

Receiving a webhook in Kaisa

Setting up and Inbound Webhook is a bit more advanced, so we have a dedicated article explaining all the steps you need to follow and the prerequisites to set it up. 

You can read more about sending data to Kaisa in our Developer Site.

Once that is sorted, you can select the "A custom event is received" option as criteria, and decide what to do next (for example send an email or an sms with the data from the payload Kaisa has received from you).

Hopefully this is helpful but any questions let us know!