I am sure anyone who has ever worked on Cisco UCCX and engaged in at least some sort of a development work would not use the words UCCX and API in the same breath. Although UCCX’s agent/supervisor interface called Finesse does offer a bunch of REST API options to play around with but the parent product is pretty limited in its offering of such modern contemporary options. Of course, we can use UCCX’s REST APIs to do some basic administration stuff but if one really wants to interact with UCCX’s database through a 3rd party application then the primary way is going to be through an integration using traditional ODBC connections.

That’s all fine!! We are not going to spend time lamenting on Cisco’s unwillingness to modernize UCCX over the years. If they haven’t done it till now then they are not going to do it in the future as well especially since CCaaS is poised to completely take over this segment in the near future. The reason I’ve dared to utter UCCX and REST in the same breath is different. Instead of moaning about the lack of serious API options available to access UCCX’s features/database, we will be looking at how the UCCX’s REST option in the script editor can be used to integrate its IVR component with other products through REST APIs. This is going to be a two part series and as always, we will first go through some basics and then follow it up with a practical use case.

If you are not sure what REST is then I’d suggest going through couple of my earlier posts where I have explained what REST standard is and what operations can be performed using it. Also, it is assumed that you already have good experience with UCCX Scripting. If you are not comfortable with REST API operations and CCX scripting then this series might not be for you yet.

UCCX Script Editor

This is the familiar view of the UCCX Script editor software. On the right is where we write our scripts and on the left, we have different modules and functions that can be used to write scripts.

Since we are focusing only on the REST operation, you can expand the “Document” option on the left and drag the “Make REST Call” function to the right.

At this point, you don’t need to focus on the script design. We are simply going over what this function does. We will go over its practical real world use case in the next post.

REST API Function

When you right click on the “Make REST Call” step in the script and click on “Properties”, it should present you with the following screen.

I am sure those who have worked with APIs before wouldn’t find these fields too intimidating. Let’s go over the important ones one by one

• URL : This is the API endpoint that your script will make a request to. For example, if you want to get details of devices registered on Webex cloud then you would make a GET request to https://webexapis.com/v1/devices. This is going to be the URL in this scenario.

• User ID/Password : This is needed if you working with an API that uses Basic Authentication which requires a Username/Password combination.

• Method : It lists all four popular REST operations. You can select any one of them depending upon your use case.

• URL Parameters : This will be used if you are passing any query parameters along with your URL. For example, you are sending a request to an API of a mattress company’s web application to get details of only the “Foam Mattresses”. In such a case, your main URL is likely going to be https://mattress.com/api/v1/products. Since you are interested only in a foam mattress, you can pass a query parameter to the main URL like this https://mattress.com/api/v1/products?product=foam. Now, this was a hypothetical scenario because all of what I’ve mentioned in this point depends upon how the API is designed and if an option to query its data is even available to outsiders. But I hope you get the gist!!

• Headers : This is where all the standard REST headers are added. This can include any Authorization headers, Content or Accept headers.

• Body : This is used if you are sending a payload along with your request to the API. This will usually be used during POST and PATCH operations where you want to add or update the contents of the API endpoint with what you are passing through this Body step.

• Response : This will contain the response received from the API endpoint. Think of this as a variable that’s going to store the result.

• Status Code and Detail : These are going to store the HTTP response codes and their detailed name. If your request is successful then 200 and Ok will be stored in Status Code and Detail respectively.

---

I hope this post was helpful in illuminating you on how one can utilize UCCX to act either as an initiator or one of the hops while building Voice based API applications. UCCX has a very interesting capability of offering an IVR based system to the callers. Wouldn’t it be cool to offer an IVR based voice setup to the callers where they can provide DTMF inputs while the script is capturing that data and interacting with other 3rd party applications over REST APIs in real time ? I think it would be super cool and this series is my attempt to make you feel the same. Stay tuned for the next post where we build an application for a real world use case!!

If you have any feedback/suggestions then please drop it in the comments or reach me at LinkedIn. Happy Learnings!!

Let’s connect on LinkedIn