I’m developing a webhook that will be submitted to the marketplace soon, My webhook will subscribe to receiving notifications for start and end meeting events.
However, the Zoom documentation indicates that my end points must be “publicly accessible”. Presently, all of the applications in our company are hosted behind the firewall, which may be a problem.
I’m going to look into Azure Relay Services, but also considering creating another service that is hosted in the DMZ that communicates with my webhook. I’m also thinking about having my Zoom Webhook implemented as an Azure Function, of which sends Azure Service Bus messages through the firewall to handlers that may access on-prem resources.
Any other creative suggestions? I’m sure many are faced with this issue.
@michael.zoom Thanks for the information on WebSockets. This may be a viable option for us.
However, we’re also looking into using Azure Relay to create a publicly accessible endpoint that may communicate with Zoom as well as an API behind our firewall.
Have you heard of other customers using any other products to achieve the same?
@sfaraclas , just to best understand, the API behind the firewall is your own. You don’t need to make requests to the Zoom API, correct? The Azure cloud function receives the request and then communicates with a service that can access your on-prem resources.
I’m not directly familiar with Azure cloud/development ecosystem but know there are folks who may be (@donte.zoom). Sam, let me check with some other teams at Zoom and get back to you.
@michael.zoom That’s correct. Zoom will call our webhook in Azure Relay and our webhook will communicate with our on-prem API to do other things (in theory).
Our webhook in Azure Relay will only receive messages from Zoom when users start and end meetings. We will not be sending requests to the Zoom API.
Thank you for sharing your pain points and offering insight into the workarounds you’ve considered. The suggestions offered are great, and I agree with @michael.zoom that they are worth exploring further. I would be happy to check with other teams at Zoom and get back to you with more information.
To make sure I have a thorough understanding of the development pain points you are facing, I would like to gather some details about the cloud providers you are currently using. Before we move forward, let me make sure I have a clear understanding of the problem you are facing and the solutions you are considering:
Problem:
In order to receive webhook events, Zoom requires your webhook endpoint to be “publicly accessible”. For some developers, their organizations may have applications hosted behind the firewall, which may be a problem.
Potential soultions to receiving Zoom events when on-prem resources are behind a firewall:
Leverage Azure Relay Services
Create a service that is hosted in the DMZ that communicates with your webhook endpoint.
Zoom Webhook implemented as an Azure Function, of which sends Azure Service Bus messages through the firewall to handlers that may access on-prem resources.
Is that accurate, @sfaraclas? If so, I kindly ask can you provide the following information :
Are you looking for Microsoft cloud services-based solutions or are you open to solutions from other cloud providers’ work?
Can you tell me more about the cloud providers you are currently using, including any challenges or limitations you have encountered?
Is there any other requirement that the solution meets? If so, can share any additional pain points you may be facing? This will help us better understand what other options can you consider.
Or are you looking for just solutions on how best to access on-prem resources?
With this information, I will be able to better assess the situation and offer more targeted suggestions for addressing your pain points. Thank you for sharing your insights, and I look forward to working with you to find a solution.
Your definitions of our primary problem (hosting a publicly accessible webhook that may access applications hosted behind our firewall) and proposed solutions, are accurate.
Our Zoom webhook will subscribe to receiving notifications when Zoom meetings start and end, and those events will call a REST service, of which will update other on-prem applications with Zoom status information.
Our preferred solution, at this point, is using Azure Relay Services, but we’re still considering the other 2 options I mentioned and open-minded to other solutions. Sending ASB messages from an Azure function to on-prem handlers would probably require firewall changes and that’s probably true for the DMZ broker service too.
Regarding your questions:
1. We’re hoping to use Microsoft-based cloud services. If another provider offered a much better solution for this need, I could try making the case, but Azure is our standard now.
2. We’re using Azure cloud services and just starting to migrate applications and microservices to cloud-native.
3. This is our primary pain point, now. I’m sure others will surface when I start developing the webhook.
4. We are mostly in search of solutions on how best to host a publicly accessible Zoom webhook that may interact with on-prem API services hosted behind our firewall. Also, hoping to avoid opening a port on the firewall and/or making intrusive changes to our network infrastructure to support this.
@donte.zoom Thanks. I’ve created the webhook using Azure Relay, as described earlier, and it’s working out well.
However, at this point I’m unable to get by the step to Validate the “Event notification endpoint URL”. The validation is failing, but I’m pretty sure I’ve followed the instructions correctly.
Please see my code (to create the hash) and response returned to Zoom.
Splendid, @sfaraclas ! At first glance, I am not seeing where you are constructing a message with the webhook request header x-zm-request-timestamp value from the payload you received. Please take a look at this post which offers more content on how Webhooks implementation:
Temporarily, I omitted the step that validates that the request came from Zoom, as you noted. But, I’ve added that and am now comparing x-zm-signature value in the header to the hashed message and they are MATCHING.
I was hoping that would make the difference, but when I click the “Validate” button for my Event notification endpoint URL, I continue to get “URL Validation failed. Try again later”.
One unexpected observation is that when I hit the validate button and my webhook is running, the Validation Failed message is returned, but I’m getting messages on my console indicating that Zoom is calling the webhook with meeting.started and meeting.ended events.
