Alternatives to using the `host_key`

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:

  1. Create an Account-Level app, add user:write:admin
  2. 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)

This was the most common use case that we saw where the host_key value was being used. This modification would involve using the “schedule_for” property in the create_meeting endpoint. To make this possible you would need to change your account settings to support Schedule-On-Behalf permissions.

1 Like

@shariq.torres when will this update be deployed live?

We’re currently relying on the host_key for some key features in our app.

And we need some time to migrate our users to a workaround that we’re working on.

Hence the question.

1 Like

This change should be live right now.

1 Like

Hi @shariq.torres ,

We use Cisco codecs and dial them into a zoom meeting via a sip address. we would create a sip address with the following components

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.


No problem. I’m glad I could be service!

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?

Hi Shariq,

Are you able to share the link to the article/ communication sent out about this change to remove the accessibility of the host_key from the Zoom API?


In light of this change, is there an alternative method to GET an existing “host_key” value or only to SET it, per use-case 1 above? Please advise.

We sent an email to all of the Account Owners about the change and we also mentioned it in the August email about the latest releases/changes.

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.

Our user profiles are already created, so would we have to re-create them to set the user_key value?

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.

@shariq.torres any ideas on this?