With the latest update to the Zoom API, developers will no longer be able to access a user’s host_key value. We understand that this is a breaking change and may alter the workflow of some applications. Below are two possible modifications you can make instead of using the host_key value. If your use case isn’t mentioned, contact customer support and we will assist you in finding a path forward.
Use-Case 1: Enterprise customers that want to integrate Zoom user profiles with their IDP/ActiveDirectory/SSO solution
For this use case, the developer must create a new structure in their datastore that can be used to map the Zoom user_id to the host_key value. Any customer’s workflows/automations that are used to get the host_key value from Zoom REST APIs, would instead look up this value in the datastore.
Before beginning, there are some account settings that need to be altered:
Create an Account-Level app, add user:write:admin
Configure Account Settings so host_key is only modifiable by Admin
With these settings in place, now the developer’s account-level app can make an API request to set the host_key for a given user. This value should be saved to the datastore for sharing with end-users.
When should a User’s host_key be set?
New User Created on Zoom Account
SSO User changed/removed (conditional) on IDP-side
User Removed from Zoom Account
User Transferred/Disassociated from Zoom Account
Use-case 2: Scheduling meetings for someone else who will be the host (aka assistant schedules meetings for the CEO)
Our script would create the meeting and passcode and get the host key based on the users email. Now I’m stuck manually looking up each request and manually populate the host key.
This week alone we’ve done 120ish request. So what would you recommend to help populate the host key.
The reason why we included because our zoom meetings are set to disable join before host and for these meetings the host is going to be in the same room as the codec… Not joining the meeting from their own device.
Lance, I believe that the first alternative approach would work for you. With this approach, the host key is set by your system. This way when you run your script, you can just call your own database with the custom host key that you have provided.
Thanks for the response and for helping put two and two together. I’ll give that some more thought on a host key database and how that could work with our current system.
I am trying to use jwt token to get/set account settings. When i use option=security it fails. If i specify no option the GET works. Whats going on? This has really put a strain on our work flow
Also, why were we not notified of this change prior to it going live?
I’m sorry about the confusion, Tim. We did send out an email communication to the account owners telling them about this change. This change was put in place due to a security concern that we were trying to close ASAP.
Now as to your problem with the JWT token, are you trying to use this API to set the host_key value?
There is no alternative method to GET an existing host_key. That piece of info has been turned off. You can set the host_key yourself using method 1 or configure an account to be able to schedule meetings for others using method 2.
FYI, our development team uses the Zoom get user settings API method (GET /users/{userId}/settings) to retrieve a user’s “host_key” value which is made available on our internal portal. Users access a personalized portal page to view their own “host key” value, which is required to start a personal audio conference along with claiming host controls for video meetings.
In your use case, you can set the user’s host_key to whatever value you see fit and save that to your database when the end-user creates a profile You would then have to send the host_key value over to Zoom so that we match it with our user records. From then on, you could display the host_key on the personalized portal page by querying your database. I think that option 1 suits your use-case.
You would have to run a backfill script to fill in the host_key for your existing users. But ultimately, you would be in control of the host_key value, so you could use whatever scheme you deem fit.
Is there a way to prevent the email confirmation from being sent to individuals if we update host keys en-masse? It would be preferable if we could manage comms internally and not scare our users when we regenerate their host key.