Changes from 8.5 to 10 Unity CUMI API access?

I was wondering if anyone could provide some assistance with an issue encountered testing code that is working under Cisco 8.5 Unity CUMI but soon to be deployed under the Cisco 10 Unity platform.

In the CTI OS Desktop code (all working on that end), we have some custom code checking a call center group's voicemail box for messages.

We use the CUMI API call as formatted:

https://<server name>/vmrest/mailbox/folders/inbox/messages?read=false&type=voice&userobjectid=56b2fccf-e…

The object ID is brought in via config files and appended to the end. Using our existing Unity credentials with the proper role, using this URL in a browser to our new version 10 Unity server returns the mailbox information fine and as expected. However, trying to use C# within the CTI OS Desktop and the Basic authorization method (working under 8.5) as follows (the entire base 64 encoding expanded for clarification):

string authData = string.Format("{0}:{1}", user, pass); 

request.Headers.Add(HttpRequestHeader.Authorization, "Basic " + Convert.ToBase64String(Encoding.UTF8.GetBytes authData)));

WebResponse response = request.GetResponse();

We get this trust error:

03/03/2015 13:21:33.4384 CTIOSSoftphoneCSharp.SoftphoneForm.RunCUMIQuery: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. 

     at System.Net.HttpWebRequest.GetResponse()

I have gone over the certificates and installed them locally, but if it's working from a browser, then a certificate issue is probably less likely the cause.

Is there anything new, changed, or something new to configure for allowing this access to CUMI APIs for getting some mailbox information? I have stared and compared the Cisco Unity system configuration settings and see nothing standing out, granting or disallowing access to API calls.

If there is any direction someone could lead me, it would be very appreciated.

Thanks,

Greg

Couple things:

1. Security got much tighter with 10.0 and it wasn’t Unity Connection – it’s all products shipping on the VOS Red Hat platform (which includes Unity Connection among many others).  Basic authentication will work for the occasional call but too many calls too quickly will be treated as an attack and rejected – likely what you’re seeing there.  You should be using the keys in the header once you get your first authentication and use that – typical key expiry, reissue type setup most HTTP based API follow.

2. If that makes you sad, you can use the C# SDK me and my team use to make most of our public facing applications - http://www.ciscounitytools.com/CodeSamples/Connection/CUPI/CUPI.html

Yes – it takes care of handling the header key extraction and reissue on expiry and all that good stuff – might save you some time if you’re already a .NET house.  It's even on NuGet.