Webhooks
This section explains each of the webhooks that can be declared within the Cockpit to improve the user experience and give the user a customized conversation for his needs
Last updated
This section explains each of the webhooks that can be declared within the Cockpit to improve the user experience and give the user a customized conversation for his needs
Last updated
To learn more about eva's features that use webhooks:
The webhooks have the same base request, called conversation event. The information in this event is common for all webhooks, and each one add the information needed for its execution.
In the Cockpit, when creating an answer, there is an option to mark the answer as “transactional”. If this option is checked, the webhook field appears. Enabling this options means that this answer has dynamic content that must replaced by the webhook.
When this answer is executed by eva, the webhook is called so it can modify the answer before delivering it to the user. This functionality is used to make answers dynamic.
This service will add the following fields to the basic request body.
This service will add the following fields to the basic response body.
When eva is executing an answer marked as transactional, it will send a request like the one below. In this example, the user said “hi there!” and we want to greet the user back, but replacing the [NAME] string with the user’s name.
Continuing the example above, this webhook will call another service to fetch the user info using the id that is stored in the hiddenContext (this data cannot be shared with other systems).
After calling another service, we will load the user data inside the safe context and change the content of the answer.
While the Transactional answer is used to dynamically change the content of the answer, the Service cell is used to change the flow of the dialogue. For example, when a user asks for his balance, the virtual agent might have to check if the user is a client before continuing the flow, fetching his balance (giving a transactional answer) if he is a client or asking him if he wants to become one if he is not a client.
In this example the service is called to check if the user is either a CLIENT or NOT_CLIENT.
This service will add the following fields to the basic request body.
This service will add the following fields to the basic response body.
In this example we will check if the user is a client or not using an ID that is present in the context.
The example below is telling the Dialog Manager to execute the flow continuing from the CLIENT option.