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.

Deprecation of the has_voicemail and has_recording responses in Phone API

Zoom is deprecating the following responses in the Get call log details and Get user’s call logs Phone APIs and the Callee call log completed and Caller call log completed Phone webhooks. We will completely remove these responses in a future release:

  • has_voicemail
  • has_recording

We replaced these deprecated responses with the call_id and call_log_id responses as follows:

We recommend that you use the new call_id and call_log_id responses in place of the deprecated responses.

How can I determine if a call log has a recording or voicemail?

You can use the new call_id property to associate call logs and recordings.

When making an API request to the Get account’s call logs API or the Get user’s call recordings API you will see that each call log or recording includes the call_id property. For example, in the Get user’s call recordings API’s response:

{
"next_page_token": "ABCDEFG1234567890",
"page_size": 1,
"total_records": 1,
"from": "2021-06-16",
"to": "2021-07-16",
"recordings": [
{
"id": "44444c6666666666a555555555f0e0c0",
"caller_number": "1234",
"caller_number_type": 1,
"caller_name": "user@example.com",
"callee_number": "5678",
"callee_number_type": 1,
"callee_name": "Username",
"direction": "inbound",
"duration": 6,
"date_time": "2021-07-12T06:39:02Z",
"recording_type": "OnDemand",
"call_log_id": "77777c77-7777-4444-b999-666666d6d6c6",
"call_id": "1234567890",
"owner": {},
"site": {
"id": "8g72O2rxR8MfUqZmJIFAdQ"
},
"end_time": "2021-07-12T06:39:09Z"
}
]
}

You can use the call_id value (for example, the call_id value of 1234567890) to make a request to the Get call log details API to associate a call log with a recording.

Active Apps Notifier relaunch and improvements

In the coming weeks, Zoom will be relaunching the Active Apps Notifier (AAN) with improved functionality based on valuable feedback from our developer community. We’ve used this feedback to make the changes detailed below.

  • When an app has real-time access to meeting or webinar content, the icon(s) will be shown in the AAN along with a tooltip, and accessible in the same window as the current meeting or webinar via the Meeting Information icon in the top left corner of the window.
  • The AAN will only list apps that access meeting or webinar content (audio, video, chat) during a meeting or webinar.
  • Language associated with each app in the AAN is clearer.
  • Icons will be used in the AAN in order to clarify what types of content apps have access to within a meeting or webinar.

Please reach out via Developer Support or the Developer Forum if you need assistance or have any questions about the AAN or these improvements, and how they might affect your application.

Data compliance deprecation notice

Zoom is deprecating the Data Compliance API. You should discontinue using this API as it will be completely inoperative in a future release.

The marketplace app submission & review process no longer includes this requirement. An email with more details regarding this change will be sent to all impacted developers in the near future.

IM metrics API sunset notice

Starting July 1, 2021, the existing IM metrics API will no longer provide data related to chat messages that are sent and received after July 1, 2021 by users. You may continue to use the existing IM metrics API to query data on messages that were sent prior to July 1, 2021.

We will keep the existing IM metrics API in place for the next six months in order for customers to access the dashboard’s data for usage prior to July 1, 2021 (old format of data). Additionally, Zoom will not store the old Dashboard IM data starting from this date. Similar to other Dashboard APIs, the Get IM metrics API only supports retrieving data from a month that falls within the six months. After January 1, 2022, you will not be able to retrieve any data using this API.

For usage data from July 1, 2021 and moving forward, customers will have to use the new dashboard Chat API once it’s enabled on July 1, 2021.

Alternate option

To get metrics on chat messages sent on and after July 1, 2021, use the Chat metrics API.

Web SDK and Web Isolation

When Chrome 92 releases on July 20th, the Chrome SharedArrayBuffer will only work with cross-origin isolated pages. This will affect any previously configured Web SDK clients. Therefore, you must reconfigure your web server settings and upgrade to the Web Client SDK version 1.9.5 if you want to continue using this feature.

See below for a summary of steps to configure your web server, or see the Web Isolation advanced guide in the Web Client SDK documentation for details.

To reconfigure your web server

  1. Apply SharedArrayBuffers origintrials for your domain. This temporary extension works until the Chrome 94 release.
  2. Enable cross-origin isolation for the Web SDK.
  3. Update to the Web Client SDK version 1.9.5 or higher.

Zoom OAuth Security Updates

As part of our continued efforts to improve security for Zoom OAuth App Types using Authorization Flow, we released three new security features. These features go into effect on May 16, 2021. They are recommended, but not required, and will not affect your existing OAuth apps in production until May 15, 2022. On that date we will make these features mandatory.

Support for x-www-form-urlencoded Content-Type headers

Zoom supports x-www-form-urlencoded Content-Type headers in the requests for access tokens, refresh tokens, and revoking tokens.

This Content-Type enables these requests to send parameters in the body of the requests instead of as query parameters, enabling better security.

See Step 2: Request Access Token, Refreshing an Access Token, and Revoking an Access Token in OAuth with Zoom for details.

Support PKCE for authorization_code grant_type

Zoom supports Proof Key for Code Exchange (PKCE) when requesting user tokens. This offers better security by enabling clients to use a code challenge and code exchange as part of the initial user authorization request.

See Using Proof Key for Code Exchange (PKCE) in OAuth with Zoom for details.

Whitelist URLs must explicitly define subdomains

Zoom checks the subdomain for whitelisted URLs. Therefore, be sure to explicitly list subdomains as whitelist URLs as valid redirect URLs for your OAuth flows. See Generate App Credentials in Create an OAuth App for details.

IM APIs deprecation notice

In December 2021, Zoom will stop supporting the IM groups and IM chat APIs in favor of a consolidated set of APIs under Groups and Chat APIs. The endpoints that will be deprecated are listed below.

IM directory APIs

All of the IM directory APIs will be removed from the Zoom API collection in December 2021 as this feature will no longer be a standalone feature in the Zoom product. We will be consolidating IM directory groups with the Groups feature and will be providing a new set of APIs that replace this feature in a future release.

APIs Endpoints
Create an IM directory group POST /v2/im/groups
List IM directory groups GET /v2/im/groups
Retrieve an IM directory group GET /v2/im/groups/{groupId}
Update an IM directory group PATCH /v2/im/groups/{groupId}
Delete an IM directory group DELETE /v2/im/groups/{groupId}
List IM directory group members GET /v2/im/groups/{groupId}/members
Add IM directory group members POST /v2/im/groups/{groupId}/members
Delete IM directory group members DELETE /v2/im/groups/{groupId}/members/{memberId}

IM chat APIs

The IM chat APIs provide authorized users with access to data associated with IM chat history. Account owners and admins can also find this data by navigating to Zoom Admin Portal -> Account Management -> Reports -> Chat History -> User Activity.

All existing IM chat sessions APIs that provide this data will be removed from the Zoom API collection.

We will be providing new APIs that replace the IM chat sessions APIs in a future release.

APIs Endpoints to be deprecated Alternate solutions
Get IM chat sessions GET /v2/im/chat/sessions We will be providing a new report API that can be used as an alternative for this API in a future release.
Get IM chat messages of a session GET /v2/im/chat/sessions/{sessionId} We will be providing a new report API that can be used as an alternative for this API in a future release.
Get user’s IM chat messages GET /v2/im/users/{userId}/chat/messages Use List user’s chat messages API.
Send IM messages POST /im/users/me/chat/messages Use Send a chat message API.

Required Web SDK update - January 10, 2021

To complete alignment with Zoom’s security initiative, including the new AES 256-bit GCM encryption, we will disable un-encrypted audio within meetings that are not using AES 256-bit GCM audio encryption starting on Sunday, January 10, 2021.

As a result of this change, we are requiring all Web SDK users to upgrade their Web SDK integrations to the latest available version 1.8.5 that supports AES GCM encryption audio to avoid service interruptions.

Please note that as of January 10th, all older versions of the Web SDK (versions 1.8.3 and below) will no longer have computer audio functionality within meetings.

To get started with the latest version of the WebSDK, please visit the Zoom Web SDK documentation page, where you can also download our Sample Web app or our npm module.

For a full list of details about recent Web SDK changes, please visit our developer change log page.

Determine latency in webhooks delivery

We understand that our customers expect webhooks delivery to be near real-time. However, in certain cases there can be a delay. In the December 2020 release, we included the event_ts parameter in the payload of all Webhooks. This field represents the timestamp of when the associated event occurred.

If you keep track of notification delivery timestamp in your application, you can determine the latency in webhook delivery by calculating the difference between the delivery timestamp and the value of the event_ts parameter.

Upcoming meeting security enhancements

On December 19, 2020, a security setting named “Require that all meetings are secured with one security option” will be added to the account settings of all Zoom customers. This setting is auto-enabled and locked for Pro, Business(with 10-100 licenses) and EDU(K/12 Free) accounts. All meetings scheduled by these accounts are required to be secured with one of the following security options: a passcode, Waiting Room, or “Only authenticated users can join meetings”. This requirement may only be disabled by account owners or admins in Enterprise, ISV, Business (with more than 100 licenses) and paid EDU accounts.

If one or more of these meeting security settings(passcode, waiting room, authentication) are enabled on the account but not locked at the account or the group level, users may choose which setting to enable or disable while scheduling the meeting. On September 27, 2020, we included 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 query parameter to view settings that have been enabled on the account.
  • From locked account settings, you can use the meeting_security query parameter to view meeting security settings that have been enabled and locked for all users in the account.
  • From user settings, you can use the meeting_security query parameter to view meeting security 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, Waiting Room or Authentication settings will be required for all meetings that are hosted by accounts that have enabled the “Require that all meetings are secured with one security option” setting. Comply with this requirement by using at least one of the following options while scheduling and updating meetings via Zoom APIs:

a). Provide a valid value for the password field.

b). Set the value of waiting_room to true.

c). Set the value of meeting_authentication to true and provide a valid value for the authentication_option field.

If you do not comply with this requirement and disable all three meeting security settings( password = null , waiting_room = false , meeting_authentication = false), Zoom will overwrite the value(s) provided in the request to enable at least one of these settings. In such scenarios, note the values returned in the response body of Create a meeting request or use the Get a meeting API to retrieve and store accurate information regarding the security settings that have been applied to the meeting.

Refer to the API enhancements for meeting security requirements page to learn more details about how these settings can impact the response of your meeting creation and update requests in different scenarios.

Upcoming changes in Windows and macOS Client SDKs

Client SDK 5.4 is currently scheduled to be released by the end of December, 2020. In this release of the Windows SDK & macOS SDK, the following changes will be introduced and it might affect your integration once you upgrade to SDK 5.4.

  1. We are adding new interfaces for multi-pin and multi-spotlight features and deprecating old interfaces.

    To add support for multi-pin and multi-spotlight features in the Zoom Client SDK, we are going to introduce new interfaces in the December release. However, due to design differences between multi-pin/multi-spotlight features and single-pin/single-spotlight features, we will be deprecating some of the existing interfaces that supported the older design. The following interfaces and parameters will be deprecated in the next release:

    • Windows SDK

      • virtual SDKError PinVideo(bool bPin, bool bFirstView, unsigned int userid) = 0;
      • virtual SDKError SpotlightVideo(bool bSpotlight, unsigned int userid) = 0;
    • macOS SDK

      • The parameters ActionMeetingCmd_PinVideo_ and ActionMeetingCmd_UnPinVideo_ that were being used in the (ZoomSDKError)actionMeetingWithCmd:(ActionMeetingCmd)cmd userID:(unsigned int)userID onScreen:(ScreenType)screen interface will no longer work after this release.

      • The parameters ActionMeetingCmd_SpotlightVideo and ActionMeetingCmd_UnSpotlightVideo that were being used in the (ZoomSDKError)actionMeetingWithCmd:(ActionMeetingCmd)cmd userID:(unsigned int)userID onScreen:(ScreenType)screen interface will no longer work after this release.

  2. We are migrating screen share related interfaces in IGeneralSettingsContext (win) and ZoomSDKGeneralSetting (mac) to IShareSettingContext (win) and ZoomSDKShareScreenSetting (mac) respectively.

    With the increasing number of screen sharing interfaces being added to the SDK, we have decided to move screen sharing interfaces from the general setting class to share setting class in the December release.

    The following interfaces in GeneralSettingsContext (win) and ZoomSDKGeneralSetting (mac) will be moved to IShareSettingContext (win) and ZoomSDKShareScreenSetting (mac) respectively:

    • Windows SDK
      • virtual SDKError EnableAutoFitToWindowWhenViewSharing(bool bEnable) = 0;
      • virtual bool IsAutoFitToWindowWhenViewSharingEnabled() = 0;
      • virtual SDKError EnableAutoFullScreenVideoWhenViewShare(bool bEnable) = 0;
      • virtual bool IsAutoFullScreenVideoWhenViewShareEnabled() = 0;
      • virtual bool IsCurrentOSSupportAccelerateGPUWhenShare() = 0;
      • virtual SDKError EnableAccelerateGPUWhenShare(bool bEnable) = 0;
      • virtual SDKError IsAccelerateGPUWhenShareEnabled(bool& bEnable) = 0;
      • virtual SDKError EnableRemoteControlAllApplications(bool bEnable) = 0;
      • virtual bool IsRemoteControlAllApplicationsEnabled() = 0;
      • virtual SDKError EnableGreenBorderWhenShare(bool bEnable) = 0;
      • virtual bool IsGreenBorderEnabledWhenShare() = 0;
      • virtual bool IsLimitFPSEnabledWhenShare() = 0;
      • virtual SDKError EnableLimitFPSWhenShare(bool bEnable) = 0;
      • virtual LimitFPSValue GetLimitFPSValueWhenShare() = 0;
      • virtual SDKError SetLimitFPSValueWhenShare(LimitFPSValue value) = 0;
    • macOS SDK:
      • -(int)getLimitFPSValue;
      • -(ZoomSDKError)setLimitFPSValue:(int)value ;
      • -(ZoomSDKError)setLimitedFPSValue:(ZoomSDKFPSValue)value ;
      • -(BOOL)isEnableToSetLimitFPS ;
      • -(ZoomSDKError)setEnableLimitFPS:(BOOL)enable ;
      • -(ZoomSDKError)enableSetShareScreen:(BOOL)enable SettingCmd:(shareSettingCmd)shareCmd;
      • -(BOOL)isEnableToSettingShare:(shareSettingCmd)sharing;

We will be deprecating the following interfaces in Windows SDK in a future release(not December release).

  • virtual SDKError EnableAutoFitToWindowWhenViewSharing(bool bEnable) = 0;
  • virtual bool IsAutoFitToWindowWhenViewSharingEnabled() = 0;
  • virtual SDKError EnableAutoFullScreenVideoWhenViewShare(bool bEnable) = 0;
  • virtual bool IsAutoFullScreenVideoWhenViewShareEnabled() = 0;

If you are currently using these interfaces, we recommend that you use the following interface instead to achieve the same functionality:

  • virtual SDKError SetWindowSizeTypeWhenViewShare(WindowSizeType eType)

The changes listed for December release will not impact your app with the SDK package that you are currently using. However if you decide to upgrade to version 5.4 of the Windows and MacOS client SDKs, these interfaces will no longer work. If you are not using the interfaces listed above, these changes will not impact your integration when building with the 5.4 or higher versions of Windows SDK and macOS SDK.

Changes in the Electron SDK

Version 5.2.42037.1112 of the Electron SDK is scheduled to be released by November 17, 2020. In this release, we will be adding support for Protocol Buffers.

If you are building your own version of the Electron SDK, you will need to follow these steps:

  • Download protobuf 3.4.0 source file and rename the src folder to protobuf_src.

  • Copy the src folder into the lib/node_add_on folder.

  • Run the build_nodeaddon script as listed here.

If you would like to use recent versions of protobuf(higher than 3.4.0), in addition to following the above steps, you must also do the following:

  • Download the execution file of the corresponding protobuf and add its directory into the system path.

  • In the terminal, navigate to the root directory of the Electron SDK(same level as the build_nodeaddon file).

  • Run protoc.exe —js_out=import_style=common.js,binary:. lib/electron_sdk_proto command in the terminal to generate a electron_sdk_pb.js file. After generating this file, you will be able to use the interfaces provided by the Electron SDK.

If you are not building your own version of the Electron SDK and are using the Electron SDK provided by Zoom, this change will not impact your app and no further action is required on your end.

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 deprecation of legacy webhooks

In January 2019, Zoom announced it would begin sunsetting all the legacy V1 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
}