In this article we'll introduce the concept of validation webhooks in Conversational AI Cloud and what it means for a developer to work with them.
If you want to know more about the request and response for the validation webhook go to the API reference section here
Validation webhooks are used to validate the slots in a transactional dialog. If there are multiple slots configured with validation webhooks for a single transactional dialog they'll get called in parallel.
A validation webhook can serve a variety of use cases, but are generally scoped to working within the confines of that specific transactional dialog slot however, as it is a webhook use cases are endless. Validation webhooks can be used to:
- Validate provided user input against an external system like a CRM or OMS.
- Validate provided user input against custom logic defined within the webhook.
- Provide dynamic quick replies based on the state (session) of the conversation.
- Provide dynamic metadata that'll be passed along to the caller of the Gateway API.
When working with the validation webhook its important to keep a few things into account:
- Since all validation webhooks will be called in parallel, you will receive calls on your webhook that aren't for the "active" slot. Make sure to always check if the call you're receiving is meant for the slot that your webhook is being called for. You can do this by checking matching the "inputSlotName" with the "slot.name" values in the input. If they match, the input you're provided with is for the slot your end-user saw.
- Only set the "success" value to false if you want the "generic error message" to be returned. The success value should be set to true in all other circumstances. A valid scenario could be an unexpected internal error within the webhook.
- It is not possible to mutate the state of the conversation (session) directly from a validation webhook.
- Each validation webhook receives the entire state of the conversation automatically, make sure to use it to determine whether you already have the value you're planning to ask the user for. E.g., if you already have the postal code available in the conversation session, there is no need to ask the end-user for their postal code again, simply pre-fill it through your webhook.
- Any output that'll be presented to the end-user will come from the webhook (if configured) this means that any message going to the end-user can be fully dynamic.
Updated about 1 month ago