We want to create a headless C# program that automatically checks certain user inboxes for new Fax or Voicemail every 5 minutes. Using "Client Credentials Grant" for authorization would make sense, but the problem is that the client once authenticated has no way to access Fax/VM of particular users. You have to instead authenticate as each user you want to check.
How can this be automated using Implicit Grant or Authorization Code Grant? Obviously I can't display an embedded browser every 5 minutes and have a human physically enter credentials. Is there a way to bypass the manual login and provide the username/password in code?
Thanks
To get around the problem I ended up creating a little GUI for the program with an embedded webbrowser control. I direct it to the PureCloud login page, and then inject some javascript to make it automatically log in without human interaction. From there I can capture the token and make authenticated API calls to get Voicemails and Faxes for the user.
FYI, we use this as a workaround for PureCloud's lack of support for Group Voicemail and Group Fax. Now we have a single "dummy user" that receives all voicemails and faxes intended for our various department workgroups. The program I wrote logs into the dummy users's account and downloads the VM/fax files from PureCloud and distributes them to the proper group email addresses.
If anyone else is interested in using this, let me know and I'll put it on GitHub.
Thank you for posting your solution and using PureCloud APIs. While we do not have a viable solution today to solve the problem at hand, we cannot recommend the approach you have taken as a workaround. Using a 'catch-all' account in the manner you describe should be considered insecure solution and would not be supported, nor recommended by us. If you choose to use this solution, you are doing so at your own risk.
That being said, you raise the issue of "what would a supported solution be?" The answer is that we do not have an answer for this today. There are at least 3-4 use cases and solutions which would be needed to handle them. I will ensure that these concerns are captured with the appropriate product team.
Understood, thanks. We eagerly await a more correct official solution. I'm told that group/queue voicemail and fax are being worked on currently, so once released that will meet our needs. I've also heard that an option to include the voicemail/fax file as an attachment in the notification email is being worked on as well. That would be an even simpler way to solve the problem.
We'll keep our ear to the ground for those features. Once one or both is available we can turn off this particular API workaround.
Thanks again
Awesome! Group voicemail and voicemail attachments to email are higher in the hopper than group fax right now. All are in a backlog status awaiting prioritization. I would anticipate that the voicemail attachment to email will probably get done quicker than the others. We have wanted to sneak that one in for a while. I hope we can get these done to help you out as quickly as possible, but I do not have any dates right now. Thanks again for your input and contributions to the community!
Hey Benjamin, I was just checking up on this again - thanks for asking about this at this week's webinar. The VM APIs are all in the context of a user, so the method you're using for authorization would be the only available method for a headless app.
There are changes coming to the login page for multi-org login, MFA, and other options that will most likely break an approach that circumvents a human proving their identity. The other option is to use a SAML assertion to create an access token. Check out this post: SAML2Bearer
I'm not very familiar with SAML2, but I'll look into that, thanks. Another simple way to solve all of this might be to add a few extra endpoints that allow an authenticated Client Credential app with Admin permissions to access the voicemail and faxes of other users, by passing in a user ID. Such apps are already able to access the conversations of other users, so accessing their VM/Fax I would not imagine is much different. Or, alternately, the ability to assign a specified user context to a Client Credential app.
That would open up a lot of capabilities for 3rd party apps to do things like email attachments to the user/group, etc. Just a thought.
Thanks for the input from everyone. What we're doing is a sufficient band-aid for now.
Are you still willing to share your code? We are faced with the same shared voicemail solution but what you described would work until at least voicemail attached to email is released.
Thank you.
Hi @Howard_Seay,
I'd be happy to share the code, but it's important to note what Bill and Chuck say above:
This is not an officially supported or recommended way of doing this. And a future change to the PureCloud login page could easily break this code.
That said, if you're still interested I can make the code a bit more generic and put it on GitHub.
One other thought that might work for you too:
PureCloud has a new Group Ring Voicemail feature in pre-release testing right now. It allows your Communicate Groups (not ACD Queues) to have a shared voicemail. A message left for the group shows up in the Inbox for all members of that group. If you think that would work for you, you might talk to your account manager about getting your org access to the pre-release feature.
(Documentation about using group voicemail is under Edit Group Properties here, and here)
Unfortunately we are using ACD queues in Architect and transferring calls to Voicemail during off hours or if a call does not get answered. It sounds like a "Group" voicemail box won't be addressable in architect. I understand the implications and like your scenario, the workaround will only be necessary until a solution is provided. Thank you @BenjaminRamsay
Ok, I'll post a link to my workaround on here when I get a chance.
Although... your comment just gave me an idea. You can transfer a call to a Group in Architect, but not to a Group's Voicemail. However, you could create a Group and give it a 1-second ring time before it goes to voicemail. Then transfer to that Group in your Architect flow. The caller would hear one ring, and then be able to leave a voicemail for that group. You'd give the Group the same members as the ACD Queue so that all the right people receive the VM.
Just a thought, I may test that out in my context. Though that only works for voicemails, so I'll still need my dummy user for group faxes.
@Howard_Seay, here you go:
It's a bit ugly, but it'll give you the idea. Overall though, I think my idea above of transferring to a 1-ring Group from Architect is probably the more reliable way to go. Once the Group Ring Voicemail feature is available for general release that is.