Zoom utilizes webhooks as a medium to notify third-party applications (consumer applications) about events that occur in a Zoom account. Instead of making repeated calls to pull data frequently from the Zoom API, you can use webhooks to get information on events that happen in a Zoom account. The account must install your webhook-enabled app to authorize data flow via webhooks.
Event notifications are sent as HTTP POST requests in JSON to the endpoint you specify in your Marketplace app. This URL must be secured over HTTPS.
Objects, actions, and events
Objects are pieces of data that form the resources provided by Zoom, such as Zoom APIs and webhooks. An event occurs when a user performs an action that causes a change in the value of an object. Events are grouped into the following types:
- Zoom Rooms
- User Activity
- Zoom Phone
- Chat Channel
- Chat Message
Each Zoom event type is comprised of multiple webhook events. These webhook events are defined by a common
$object.$action naming rule.
For example, the
user webhook object consists
action values such as:
One of the User webhook events is the
user.created event. This webhook triggers when a user is created on a Zoom account that is subscribed to the User has been created event in the User event type.
To enable webhooks for these events, you must add Event Subscriptions to your Marketplace app. Refer to the Enable webhooks section for information on enabling webhooks with event subscriptions for each app type.
You can enable webhooks in any of the following Zoom App Marketplace app types:
Select this app type to securely integrate with Zoom APIs and access users’ authorized data with a user-based authentication approach. This app can either be installed and managed across an account by account administrators (account-level app) or by users individually (user-managed app). You can also publish this app on the Zoom App Marketplace and make your app accessible to millions of Zoom users.
Select this app type to establish server-to-server interactions with the Zoom API.
Select this app type if your app requires user information only on events that you subscribe to and does not require data from Zoom APIs. This app type only activates in your Zoom account and you can only subscribe to events that occur in your Zoom account.
Select this app type to let your app interact with Zoom users on the Zoom client via chat. You can subscribe to events that occur on your own account or any other accounts that install your Chatbot.
To enable webhooks for each of these app types, you must perform the following steps:
Create an app on the Zoom App Marketplace. Select an app type and provide any required information when you create the app.
Provide a valid, HTTPS-secured Event Notification Endpoint URL. This is the designated URL of your app where you will receive webhook POST requests (event notifications). The notifications are sent each time an event that your app is subscribed to occurs in a Zoom account of a user that has installed your webhook-enabled app.
On the Features page of the app’s Dashboard, enable Event Subscriptions. Select from the available Event Types that you want to subscribe to, then click “Done”. Save the configurations for the Event Subscriptions.
To add additional Event Subscriptions, click “+ Add new event subscription”. Although you can subscribe to as many events as needed for each event subscription, you can only have a maximum of 10 event subscriptions per app.
Event Subscriptions can have duplicate Events. For example, one Event Subscription can have the Meetings and User events, and a second Event Subscription can have the Meetings and Recordings events.
Optionally, you can customize other available app features, such as Scopes and Chat Subscription, as needed.
After one of your subscribed events triggers on your Zoom account or any other Zoom account that has installed your webhook-enabled app, Zoom will send an event notification to your app’s Event Notification Endpoint URL in the form of an HTTP POST request. This request includes a JSON Request Body and multiple Headers.
The webhook sent by Zoom contains the following headers:
||The server host to which the request is being sent.|
||The resource’s media type.|
||The content length of the HTTP request body, in bytes.|
||The unique ID that Zoom uses to identify the request.|
||This header is unique to your app and confirms the validity of the request. To verify if a request is sent by Zoom, compare the
||The identifier of the application that is sending the request. For example,
||The client ID of your registered Marketplace application that is receiving the request.|
||The trace ID Zoom uses for load balancers.|
The request body includes event information, such as the event type that occurred, the
account_id (a unique ID for a Zoom account) in which the event occurred, and information in an object containing the fields whose value(s) changed during an event.
We strongly recommend that you use verification tokens to verify whether the event notifications that you receive originate from Zoom. We also do not recommend whitelisting by IP addresses because Zoom may update the IP ranges used at any time.
Instead, refer to the following list of IP addresses that Zoom uses to send event notifications:
22.214.171.124/25 126.96.36.199/23 188.8.131.52/25 184.108.40.206 220.127.116.11 18.104.22.168/16 22.214.171.124/16 126.96.36.199/16
After receiving a notification, your Event Notification Endpoint URL should respond with either a
200 or a
204 HTTP status code within three seconds. After that, Zoom considers the notification successfully delivered.
For any unsuccessful notification deliveries, Zoom attempts to deliver the event notification three times:
- The first attempt is sent five minutes after the initial notification delivery attempt.
- A second attempt is sent 20 minutes after the first attempt.
- A third attempt is sent 60 minutes after the second attempt.
2XX response is received after any retry attempt, then the event notification is successfully delivered.
However, if Zoom does not receive a
2XX response after three attempts, then no further notifications related to that event will be sent to your app’s Event Notification Endpoint URL.
event_ts response is included in the payload of all event notifications. This represents the timestamp for when the associated event occurred.
If you track notification delivery timestamps in your application, you can determine the latency in webhook delivery by calculating the difference between the delivery timestamp and the value of the
Explore various Zoom webhooks, learn about their payloads, and view examples in the following sections. You can also read the Automate Workflows With Zoom Webhooks blog for a quick webhook walkthrough.
Ready to use webhooks in your app? Start building on the Zoom App Marketplace.