Announcements

Below are upcoming and recent backwards compatible changes made to the Zoom Developer Platform. For other recent changes to the Zoom API, Marketplace and SDKs, refer to our Changelog.

Upcoming Waiting Room and Passcode Requirements - API Behavior Changes

Starting September 27, 2020, Zoom meetings (new meetings as well as previously scheduled meetings) hosted by accounts that are enrolled in one of the plans listed below will be required to have either a Passcode or a Waiting Room enabled:

  • Pro
  • Business with 10-100 licenses
  • EDU - K/12 Free

This requirement has already been in effect for free accounts and from September 27, 2020, this will also be applied on the accounts that are enrolled in the plans listed above.

Account owners or users with admin roles can enable passcode and waiting room settings. Optionally, they can also lock these settings to disallow users from being able to change it. If a setting is enabled on the account but not locked at the account or the group level, users can still change the setting using the Update User Settings API.

On September 27, 2020, we will also be including the meeting_security parameter in Account Settings, Account Lock Settings, User Settings, Group Settings and Group Lock Settings API, using which you can access the meeting security settings that have been applied to users in Pro accounts, Business accounts(with 10-100 licenses) and EDU(K/12 Free) accounts.

  • From account settings, you can use the meeting_security parameter to view settings that have been enabled on the account.
  • From account lock settings, you can use the meeting_security parameter to view settings that have been force enabled on all users in the account.
  • From user settings, you can use the meeting_security parameter to view settings that have been enabled for a user. From group settings, you can view settings that have been enabled for users in a group.

API Behavior Changes

After this change takes effect, either a Passcode(identified as password in the Zoom Meeting APIs) or Waiting Room(identified as waiting_room in the Zoom Meeting APIs) will be required for all meetings that are hosted by users in Pro accounts, Business accounts(with 10-100 licenses) and EDU(K/12 Free) accounts. To meet this requirement, in some cases, the values of the password and the waiting_room fields provided in the API requests might be overwritten by Zoom.

The following table shows how these settings can impact the response of your Zoom Meetings API requests.

Create a Meeting API

Settings Request parameters Result
Scenario 1

Both Meeting Passcode and Waiting Room settings are enabled and locked for users in the account.

Waiting Room
A value for the waiting_room field is either not provided(null) or set as:

  • true
  • false
Passcode
A value for the password field is either not provided (null) or is set as:

  • Empty string (“”)
  • A valid value

Both Waiting Room and Passcode will be enabled for the meeting (i.e., in the response, the value of waiting_room will be set to true and the meeting passcode (password) provided in the request will be available in the response password field for the meeting).

Note that if you provide an empty string in the password field or do not include the password field in the request, a valid password will be autogenerated by Zoom and will be present in the response of the API request.

Scenario 2

Waiting room is disabled and locked off but the meeting passcode is either enabled, enabled and locked or disabled without a lock.

Waiting Room
A value for the waiting_room field is either not provided(null) or set as:

  • true
  • false
Passcode
A value for the password field is either not provided (null) or is set as:

  • Empty string (“”)
  • A valid value

Waiting room will remain disabled but a passcode will be generated for the meeting. If a valid value is provided for the password field, the same value will be used.

If a value is not provided for the password field, a new passcode will be automatically generated and included in the response.

Scenario 3

Waiting room is either enabled, enabled and locked or disabled without a lock but the meeting passcode is locked off.

Waiting Room
A value for the waiting_room field is either not provided(null) or set as:

  • true
  • false
Passcode
A value for the password field is either not provided (null) or is set as:

  • Empty string (“”)
  • A valid value

Waiting room will be enabled and the passcode will remain disabled for the meeting (i.e, in the response of Create a Meeting API, the value of waiting_room field will be true but a password field will not be present).

Scenario 4

Waiting room is either enabled without a lock or disabled without a lock but meeting passcode is enabled and locked.

Waiting Room
A value for the waiting_room field is either not provided(null) or set as:

  • true
  • false
Passcode
A value for the password field is either not provided (null) or is set as:

  • Empty string (“”)
  • A valid value

The value of waiting_room will depend on the value provided in the request body. If the value is set to true, if the value of the waiting room is set to false, the waiting room will be disabled.



If a valid passcode is provided in the password field in the request body, the same passcode will be applied and returned in the response.If an invalid passcode is provided, an error will be thrown in the response. If a value is not provided for the password field, a passcode will be automatically generated and returned in the response.

Scenario 5

Waiting room is enabled and locked and the meeting passcode is either enabled without a lock or disabled without a lock.

Waiting Room
A value for the waiting_room field is either not provided(null) or set as:

  • true
  • false
Passcode
A value for the password field is either not provided (null) or is set as:

  • Empty string (“”)
  • A valid value

Waiting room will remain enabled (i.e, the value of waiting_room will be true in the API response). If a valid passcode is provided in the password field, the same value will be used in the response. If the password field is not used, a passcode will not be applied for the meeting.

Scenario 6

Both Waiting room and Meeting passcode are either enabled without a lock or disabled without a lock.

Waiting Room
A value for the waiting_room field is either not provided(null) or set as:

  • true
  • false
Passcode
A value for the password field is either not provided (null) or is set as:

  • Empty string (“”)
  • A valid value

If the password field is not used in the Create a Meeting API request, the waiting room will be enabled even if the value of waiting_room is set to false.

Update a Meeting API

Settings Request parameters Result
Scenario 1

Both Meeting Passcode and Waiting Room settings are enabled and locked for users in the account.

Waiting Room
A value for the waiting_room field is either not provided(null) or set as:

  • true
  • false
Passcode
A value for the password field is either not provided (null) or is set as:

  • Empty string (“”)
  • A valid value
Waiting room will remain enabled (i.e., the value of waiting_room in the API response will be true.

If a passcode was previously not set for the meeting and the password parameter is not used in the Update a Meeting request, a meeting passcode will be automatically generated and provided in the password parameter of the response.

If the meeting previously had a passcode and a passcode is not provided in the password parameter in the Update request, the passcode that was previously set for the meeting will remain active.

Scenario 2

Waiting room is disabled and locked off but the meeting passcode is either enabled, enabled and locked or disabled without a lock.

Waiting Room
A value for the waiting_room field is either not provided(null) or set as:

  • true
  • false
Passcode
A value for the password field is either not provided (null) or is set as:

  • Empty string (“”)
  • A valid value

Waiting room will remain disabled but a passcode will be automatically generated for the meeting if the meeting previously did not have a passcode and a passcode is not provided in the password parameter during the Update request.

If the meeting previously had a passcode but a new passcode was not provided in the Update request, the meeting’s previous passcode will remain active.

Scenario 3

Waiting room is either enabled, enabled and locked or disabled without a lock but the meeting passcode is disabled and locked.

Waiting Room
A value for the waiting_room field is either not provided(null) or set as:

  • true
  • false
Passcode
A value for the password field is either not provided (null) or is set as:

  • Empty string (“”)
  • A valid value

Waiting room will be enabled and the passcode will remain disabled for the meeting (i.e, in the response of Update a Meeting API, the value of waiting_room field will be true but the password field will not be present).

Scenario 4

Waiting room is either enabled without a lock or disabled without a lock but meeting passcode is enabled and locked.

Waiting Room
A value for the waiting_room field is either not provided(null) or set as:

  • true
  • false
Passcode
A value for the password field is either not provided (null) or is set as:

  • Empty string (“”)
  • A valid value

Waiting room will be enabled if the value of waiting_room is set to true and will be disabled if the value of waiting_room is set to false in the Update request.

If a meeting previously did not have a passcode and a passcode is not provided in the Update Meeting API request, a new passcode will be automatically generated and returned in the response.

If the meeting previously had a passcode and the value of passcode is empty (password = “”) in the Update a Meeting API request, the old passcode of the meeting will remain active for the meeting.

Scenario 5

Waiting room is enabled and locked and the meeting passcode is either enabled without a lock or disabled without a lock.

Waiting Room
A value for the waiting_room field is either not provided(null) or set as:

  • true
  • false
Passcode
A value for the password field is either not provided (null) or is set as:

  • Empty string (“”)
  • A valid value

Waiting room will remain enabled (i.e, the value of waiting_room will be true in the API response).

If a valid passcode is provided in the password field, the same value will be used in the response. If the password field is not used, a passcode will not be applied for the meeting.

Scenario 6

Both Waiting room and Meeting passcode are either enabled without a lock or disabled without a lock.

Waiting Room
A value for the waiting_room field is either not provided(null) or set as:

  • true
  • false
Passcode
A value for the password field is either not provided (null) or is set as:

  • Empty string (“”)
  • A valid value

If the meeting previously didn’t have a passcode and the waiting room was not enabled for the meeting, waiting_room will be enabled by default after a request is made to the Update a Meeting API.

If the meeting previously had a passcode, the same passcode will remain active even if a passcode is not provided in the Update a Meeting API request.

Refer to the FAQ Meetings Waiting Room and Passcode Requirements, September 27, 2020 guide to learn more about this security enhancement.

Upcoming SDK Requirements

Starting with the next release of Windows SDK/Electron SDK/C# wrapper(tentative release date: 09/28), the SDKs will require Visual Studio 2019 to build an SDK application.

If you upgrade to the latest version of the Zoom SDK (Windows SDK/Electron SDK/C# wrapper) without upgrading your project to Visual Studio 2019, you will run into build errors and the project will not compile. To avoid these errors, ensure that you are using Visual Studio 2019 by September 28, 2020.

Upcoming Legacy Webhooks End of Life

In January 2019, Zoom announced it would begin sunsetting the Zoom v1 API framework along with our legacy webhooks and shifting our development resources to our new Marketplace Webhooks.

To prevent service interruptions, you must start using the webhooks currently available on the Marketplace by September 28th, 2020. No extensions will be granted.

During this time period and the end-of-support date, Zoom will not make any feature enhancements or additions to the legacy webhooks framework. After September 28th 2020, apps built or using legacy webhooks framework will no longer be available.

Migrating to our new marketplace webhooks will ensure your Zoom integrations continue to operate normally and give you access to the latest webhooks and updated payloads that align with Zooms ecosystem.

If you have any questions about these changes, or if your developers need technical support using the new Marketplace webhooks, please visit our Zoom Developer Forum and let us know how we can help.

Webinar Support in WebSDK

In the Web SDK version 1.8.0 release, we added support for users to start Webinars as hosts and for panelists and attendees to join the Webinars. Check out the Web SDK docs to learn more about these features.

New Account Level Chat APIs

The Chat and Channel APIs are no longer restricted to user level apps only. In the August API Release, we added account level scope support in Chat APIs so that you can start sending, updating, listing and deleting Zoom chat messages from Account level apps.

Early Notice: Changes coming to Batch List APIs

To provide for greater scalability of our Batch List APIs and provide for more consistent pagination methods, the pagination keys used for Batch List APIs will be changed from a page_number key to next_page_token.

Starting Q2, 2020, and over the subsequent months, a new pagination field (next_page_token) will be added to all REST API requests and responses. As of October 20, 2020, the list of APIs that do not already support next_page_token are listed below:

Once all of the above APIs have support for next_page_token, you will have a six (6) month period to migrate from page_number to next_page_token. After the six month adoption window, the page_number field will no longer operate.

A notice will be sent once all Batch List APIs have been updated to support next_page_token, at which time the six month adoption window will begin.

Developer Readiness Guide:

Batch List API requests:

Currently, for some APIs a page_number is used for pagination:

curl --location --request GET 'https://api.zoom.us/v2/groups/<GROUP_ID>/members?page_size=30&page_number=2'

During the adoption window, either a page_number or next_page_token can be used as a query param:

curl --location --request GET 'https://api.zoom.us/v2/groups/<GROUP_ID>/members?page_size=30&page_number=1'
curl --location --request GET 'https://api.zoom.us/v2/groups/<string>/members?page_size=30&next_page_token=lVSwjkBWxRCOXXNKdaezEViAQvCw1d37uq3'

After the six (6) month adoption window, only a next_page_token can be used:

curl --location --request GET 'https://api.zoom.us/v2/groups/<string>/members?page_size=30&next_page_token=lVSwjkBWxRCOXXNKdaezEViAQvCw1d37uq3'

Batch List API responses:

Currently, a page_number is sent in a Batch List response:

{
		"members": [
				{
						"email": "",
						"first_name": "Ram",
						"id": "3542342",
						"last_name": "Ghale",
						"type": 1
				}
		],
		"page_count": 3,
		"page_number": 2,
		"page_size": 100,
		"total_records": 300
}

During the adoption window, both a page_number and next_page_token will be used:

{
		"members": [
				{
						"email": "",
						"first_name": "Ram",
						"id": "3542342",
						"last_name": "Ghale",
						"type": 1
				}
		],
		"page_count": 3,
		"page_number": 2,
		"next_page_token": “lVSwjkBWxRCOXXNKdaezEViAQvCw1d37uq3”,
		"page_size": 100,
		"total_records": 300
}

After the six (6) month adoption window, only a next_page_token will be sent:

{
		"members": [
				{
						"email": "",
						"first_name": "Ram",
						"id": "3542342",
						"last_name": "Ghale",
						"type": 1
				}
		],
		"page_count": 3,
		"next_page_token": “lVSwjkBWxRCOXXNKdaezEViAQvCw1d37uq3”,
		"page_size": 100,
		"total_records": 300
}

Need help?

The first place to look is on our Developer Forum. If you can't find the answer or your request includes sensitive information, contact Developer Support.