Desperately seeking a Client ID

Authentication API
1

My company has extensive internal applications that are not cloud or web-based – they are all WPF and Windows Forms, all on-premise, etc. Many years ago, we added screen pop and other related features to these internal systems using the “prairiefyre” .net SDK (quite easily, I might add…). Mitel apparently dropped support for those tools a few years back, and in the last several months we were told that cloudlink is the way forward for us to get those kinds of features working again.

We’ve now been in various levels of hell for literally MONTHS trying to get cloudlink set up and working. The first problem was that it (apparently?) took weeks for our reseller to figure out that THEY were responsible for actually installing and/or configuring cloudlink for us. They have now supposedly done that (I say “supposedly” because I’m not at all convinced that they did it correctly, and there is even some evidence that may contravene that notion).

Our dev team is not only accustomed calling others’ REST APIs, we have our own extensive set of APIs that we manage. So we’re well aware of how this stuff works. We’ve been trying to call the authentication API, both using Postman (with the Mitel-supplied custom library), as well as following the getting started samples (such as this one: developer-api-program/sample-app/authentication-sample-code/nodejs at main · mitel-networks/developer-api-program · GitHub). In all cases, we only get this response:

{
** message: ‘The client_id you are trying to authorize is not valid’,**
** error: ‘invalid_client’,**
** error_description: ‘The client_id you are trying to authorize is not valid’,**
** name: ‘InvalidClient’**
}

All evidence we’ve seen in Mitel docs and samples indicates that this “client id” is “supplied by Mitel.” We’ve now been going round and round, bounced back and forth between our reseller and Mitel “sales engineers,” asking anyone that will listen: HOW DO WE GET A VALID CLIENT ID???

Nobody has been able to tell us this. Instead, the reseller makes recommendations like selling us Mitel API training, or sending us to Mitel Pro Services.

Again, based on all evidence I’ve seen thus far, both of those options seem insane - this should be a simple support matter. But we just can’t break down the wall.

We’ve seen the topic id 168 from three years ago on this dev portal - subject “Client ID and Client Secret.” In that other topic, Budd Renaud says the following regarding the client id to the other customer:

This is the ID that I emailed your team on July 6th.

Again, yet more evidence making it pretty damn clear that the client ID is something that has to come from someone or some thing at Mitel.

I’ve become so desperate that I also opened up an issue on the Mitel github repo that contains the API samples and documentation:

Is there someone – anyone – at Mitel that is willing to provide actual support for the Mitel CloudLink API for a very long-term Mitel customer? That can either create the client id for us, or point is in the right direction on how to get it created?

2

Hi @pwilkins - I’m really sorry that you’ve had such a challenge getting a straight answer here.

There are two different concepts of a ‘Client ID’ in CloudLink, one refers to the UUID for a ‘Client’ object that can be used as a sort of service account for authenticating against CloudLink as opposed to using user credentials.

The other (and what you’re specifically asking about) is also known as an ‘ApplicationId’ which refers to a unique application that has been deployed against CloudLink. For a third-party such as yourself to obtain a clientId, your application needs to be reviewed and approved as per the “Mitel Compatible” process outlined here - App Registration & Deployment

Don’t worry though, you can still get an authentication token WITHOUT a clientId. I can’t link directly because there’s a bug with the navigation menu, but if you go here - API Guides … look under Use Cases > User Auth - Development Only.

The short version of all this is: You don’t need a clientId to authenticate against CloudLink. You can use:

POST /token

{
   "grant_type": "password",
   "username": {{user}}
   "password": {{password}}
   "account_id": {{CloudLinkAccountId}}
}

In the Postman library it’s under Authentication > OAuth Tokens > User Token - Testing Only. We were trying to discourage people from using these at one point (hence the label), but that’s no longer the case. We’ve just not gotten around to updating the Postman library yet…

3

We got it to authenticate and am trying to create a subscription. I am using the following to crate the subscription.

applicationId = “[accountidGUID]”;
deviceId = “https://webhook.site/be7f85bb-960e-42fd-9bf4-52bc4507a444”;
transport = “webhook”;
topic = “platform-api-media”;
subjectFilter = “/2017-09-01/endpoints/2240”;
publicationFilter = “$.publications[?(@.content.state == ‘ringing’)]”;

url = https://notifications.api.mitel.io/2017-09-01/subscriptions

However when I call extension 2240, I don’t get a call to the webhook deviceid. Can you see anything I’ve done wrong?

4

The applicationId should be a GUID that you generate yourself, using the accountId might be part of the issue there. I assume the request to create the subscription was successful? If changing the applicationId doesn’t resolve the issue, please message me the subscriptionId and I’ll see if the server logs give me anymore information.

The rest of the subscription parameters look good.