It’s Now Way Easier to Personalize Your Assistant!
Introducing Webhooks in Watson Assistant
The goal of any assistant is to solve customer problems in a personalized and frictionless way. And to do this effectively, the assistant should…
- Know the customer and his/her preferences
- Be able to do things on behalf of the customer
Until now, to build a personalized Watson Assistant, you had to build your own application in front of Watson Assistant's API and use that application to manage the connections out to your CRM and/or transactional systems. The app would orchestrate the end-to-end customer interaction with the assistant. And this kind of architecture is problematic for a few reasons:
- Makes it harder to try the assistant as you’re building it
- Leads you to build a “language” of sorts to communicate with your application to tell it what to do (which complicates your dialog)
- Means you can’t use any of the pre-built channel integrations available within Watson Assistant
And that’s why we’re announcing a new way to communicate with external systems (via webhooks)!
How it Works
The webhooks feature sends HTTP requests to a single URL when one of your dialog nodes is configured to make a callout. This lets you pull in user information to personalize answers, post transactions to internal systems, check other APIs or systems for answers to questions, you name it—all in-line within your dialog.
To use the feature, head to the options tab of your dialog skill and add the URL of your application. In many cases, your app will not require any authentication — but if it does, you can optionally add headers and basic authentication.
To make a callout on a dialog node, click the configure tab on that node and turn on Webhooks. You will see that the Multiple Conditioned Responses feature will be enabled as well, allowing you to respond instantly to callbacks and be prepared for any failures that may occur.
Once you’ve enabled Webhooks, you will see a new section in your dialog node to add parameters for a specific callout (i.e. the function name or other context variables), as well as a return variable to save the response from the callback from your app.
The Multiple Conditioned Responses feature will help you more easily respond to user queries in both success and failure conditions. And you can also add more specific conditional responses, depending on how you want to respond based on the information returned from your application. Here’s an example setup:
Some More Details!
We currently allow only a single webhook URL. Why? Because this lets you easily manage all of your system callouts in one centralized web service. If you have a dev/test or production pipeline, you can easily swap out your staging URL for your production URL. Your web service should take the parameters from your dialog callout to decide what logic to run for each individual dialog node.
In the video at the top of the blog, you can see how I used a simple action parameter to guide whether to call a joke API or a fact API and return the appropriate response, all from my single web application using a simple IF/ELSE statement.
Note that I am using IBM Cloud Functions as my web service in this example, which you may already be familiar with. This is a convenient, “serverless” place to write and manage your code without having to worry about hosting or maintaining any cloud infrastructure. However, you can host your web service anywhere you like as long as it’s publicly accessible through a URL.
