This is just a general conversation to see if I’m on the right track for the usage of the API. Our program is a ASP.NET platform that has a front end that uses HTML5, and AngularJS. The product has it in the ability to include .NET scripts, and JS scripts as well.
We’re looking to add an integration using Zoom for the sake of booking meetings in conjunction with appointments in our product.
When it comes to how we are to structure the program, our platform would activate API calls against the Zoom API when certain events happen. Since our product is a platform, the extension we’re making for Zoom needs to be generic. The Assumption is the client using our solution (most are enterprise-level) will already have their own company Zoom account with users.
In terms of JWT authentication, I’m wondering how we make the extension code generic, and how the customer would hook in using JWT? Would they have to create an application in their account to obtain the authentication keys and such to form a JWT?
The main actions we would be doing is creating, and deleting meetings based on calendar bookings within our software. The assumption is that the organization will have many users, and each of those users would have appointments booked for them based on bookings in a calendar linked to the user.
Hi @rorius, this application would need to be OAuth for user-level authorization. You will need to Create an OAuth app on the Marketplace which would then be installed on a user’s account.
Generally, the agent would not be doing the creation of meetings in zoom. Internal code is trigged in the application to use the API to create the meeting for them.
Appointments in our system can be created without the contextual Zoom user’s intervention. I.E a student lets say books an appointment through their school portal. The appointment is created, at some point between that event and the actual appointment time, code would run in a job to create a Zoom meeting and send the link to the user, and add it to the agent’s information about the appointment.
When I’m creating a test application for the purpose of using the API, I needed to create a JWT to run my tests on postman. In production, would a customer create an application on their account to use the customization?
Sorry guys, I’m still not clear on this, and I’m still learning some concepts here. Also, please don’t judge me on my art skills, I’m not known for making things that look pretty.
We need to create the customization to reside in the platform. Normally we create a combination of .net DLLS and .net scripts that work within the platform to handle the events. So this customization resides in the ASP. NET platform, and has assets with the DB, and within the application bin folder if necessary. I’d like to make the customization generic so that each client can do 2 things.
Have the customization installed on the platform and configured using their credentials
Supply webhook information on their account that requires some configuration elements that are unique to each customer using the platform. (The webhooks may do the same action, but require different URL definitions to distinguish them from other clients). The hope is when each client is being configured, their webhook information can be supplied on creation.
Given that, if I’m to create the customization, JWT sounds right based on Server-to-Server, and that there is no user intervention related to the CRUD functions of a meeting.
So, to configure each client environment correctly, does installing some kind of application from Zoom cover the configuration elements of the JWT?
Would the configuration on each use of the platform require the customer to get information from their zoom account to enter in fields that are used to create it?
With other integrations in the past, the client’s account has an API Key and Secret that they enter in the configuration of our customization, and it makes the API calls using those. I’m just trying to understand what I need to do differently to achieve the same results.
We handle this flow with OAuth. Basically the user just has to click a button to give you access to read / write to their Zoom functions via the Zoom API on their behalf. You will create an OAuth app, and then your users will install it.
Does that make sense? We don’t want users sharing their API Key/Client ID and Secret Credentials.
Thanks for your response! Does the paradigm still say the same if the object “Our ASP.NET Platform” is installed in different on premesis installations? The platform is just the basis, as is our cloud platform. Because of these things, we would need to define different webhook information per zoom client using our platform
So Instituation A, B, C would all have their own Zoom accounts and Instances of our platform. The webhook they are using going into our cloud service (which also has more than 1 endpoint depending on geography, and demo/ prodcution) contains pieces of information specific to the their instance and even the Event notification endpoint URL addresses within it.
Given this, will they be able to specify this information in a marketplace applacation when they install it on their account for OAuth? I can do it these things in my development application I’m using with JWT but I can specfy the webhook information for my specific usage.
You could use an OAuth app, and add event subscriptions (webhooks) to it, and then once the respective institution installs your OAuth app, you will receive the webhooks for their account.
