When integrating with Zoom, it's important to be familiar with their recording consent requirements, how this impacts meeting bots, and what it means for your integration.

This page will walk you through these requirements, and also provide some best practices for navigating recording consent to build the best user experience.

What are Zoom's recording consent requirements?

---

Zoom requires all meeting bots to receive consent from the host of the meeting before accessing video & audio streams (for recording/transcription, or otherwise).

More information can be found in Zoom's reference here.

There are two ways the host can grant recording permission:

1. Manually approving a prompt: The host receives a popup dialog that must be approved before the bot can record. This is the default behavior.
2. Zoom OAuth: The host authorizes their account to your Zoom application via OAuth, and you provide bots with Join tokens for Local Recording to grant them access to record. This is an optional alternative to the manual consent flow.

❗️

"Record to computer files" setting

Regardless of which mode of consent your users take, a prerequisite for granting recording consent to Zoom bots is having the "Record to computer files" setting enabled here:

If these settings are not configured appropriately, the Zoom bot will be unable to get permission to record through either approach.

Option 1: Manual consent dialog

The first, most common option of obtaining consent is through the recording consent dialog.

The consent dialog is the default mode of consent - all Recall.ai Zoom bots will prompt the host in this way without any configuration needed.

In practice, this looks like:

1. Bot enters the Zoom call
2. If the host is present, they will receive a recording consent dialog that they must approve
3. Upon receiving confirmation, the bot will begin recording

Option 2: Join tokens using Zoom OAuth

The alternative to the manual consent flow is having the user connect their account to your Zoom app via OAuth. Once connected, their OAuth token can be used to fetch a Join Token for Local Recording, which is then provided to a bot to grant it recording privileges.

From an end user's perspective, this can be a better experience since they do not have to explicitly approve their bot every time they bring it to one of their own meetings. It's also particularly helpful for use cases where the creator of the meeting doesn't actually plan on attending.

📘

Zoom OAuth does not apply to external meetings

It's important to note that since recording permissions are tied to the host of a given meeting, the OAuth integration does not enable automatic recording privileges in meetings that are not hosted by the user themself (or organization, in the case of account-managed apps).

In this case, the bot will fall back to the default manual consent prompt.

From an integration perspective, our API provides several ways to provide bots with Join Tokens for Local Recording, which can be found here.

The most straight forward approach is to leverage Recall-managed Zoom OAuth, which abstracts away much of the implementation and complexity, such as handling Zoom webhooks, managing/refreshing OAuth tokens, and generating join tokens and providing them to bots.

Which form of consent should I choose for my product?

Generally, the default behavior of explicit consent is a great starting point for most products. Most people choose to opt for the default behavior of explicit consent, and explore adding a Zoom OAuth integration later if needed.

With that said, you may want to consider the Zoom OAuth integration if one of the following applies to you:

• You have a legitimate use case where the Zoom account creating meetings does not actually attend those meetings.*
• Your users are often signed out of their Zoom client, or switch between different accounts
• Your users don't want to grant the bot recording permission every single meeting

*The most common example is using a service account to schedule meetings on behalf of your users.

Common failure modes

---

With the above consent requirements in mind, there are a few best practices we recommend to ensure a smooth experience when integrating Zoom bots into your product.

You will inevitably run into scenarios where a user's bot is unable to record, and so it's helpful to provide them with feedback and instructions on how to resolve these issues.

Improperly configured local recording settings

As mentioned above, the user must have the Record to Computer Files settings enabled and configured properly in order for the bot to be able to prompt them for recording consent (or generate a Join Token for Local Recording in the case of OAuth).

There are a few different ways the user's recording settings can be misconfigured, and all of these failure modes are surfaced through the Recall.ai API as a recording_permission_denied Bot Event.

The sub_code of the event will highlight which specific setting the user needs to check.

How to resolve

The table below details the possible failure modes and the action the user should take to resolve this:

Host was not present or did not see the consent

Sometimes a bot joins a meeting but is unable to record because it was unable to ask for recording permission. In this case, this means the host was not present and thus was unable to grant recording permissions to the bot.

You'll be able to identify this scenario because none of the bot's meeting_participants will have is_host: true.

The bot's status_changes will also not have a recording_permission_allowed or recording_permission_denied event and will remain in the in_call_not_recording state until it times out or the call is ended.

How to resolve

Many users have multiple Zoom accounts and they'll need to ensure they're joining the meetings from the same account as the one they're creating meetings from. If the end user needs to support granting recording permissions from various Zoom accounts, they can assign their alternative account(s) as alternative hosts.

If this is a common failure mode for your users, you might also consider adding the Zoom OAuth integration.

📘

But the user said they were the host and were present, why are they showing as is_host: false?

If the end user that created the meeting is not showing up as the host, one of two things is going on:

• They are not signed into the Zoom account where the meeting was created from*
• They are not signed into their Zoom client at all

*One common way this can happen is if the user's meetings are being created using the Zoom Google Calendar add-on. Their add-on may be connected to a different Zoom account than the one they're signed into from their Zoom client.

Best practices for mitigating recording failures

---

Onboarding: Have your users check their recording settings up-front

Since Zoom recording permission relies on the user's Record to computer files setting being enabled, we highly recommend having a step in your onboarding flow that instructs users to configure their settings appropriately.

Feel free to copy the below language and screenshot to include in your own application or help documentation:

Important: Zoom Meeting notetakers

Due to how Zoom's recording permissions work, you must have your "Record to computer files" setting enabled in order for meeting notetakers to be able to record.

To verify this, navigate to your Zoom recording settings [here](https://zoom.us/profile/setting?tab=recording) and ensure the settings below are enabled:

Having your users check this setting during your onboarding will ensure they're set up for success, and can help prevent recording failures once they begin using your notetaker.

Surfacing recording errors & instructions to resolve them

While having users check their recording settings during your onboarding can help avoid most recording issues, your users may still run into recording failures later down the road.

In these cases, it can be helpful to surface the reasons for these failures to your user, and provide them with actionable steps to resolve them.

To do this, we recommend leveraging chat messages, adding actionable errors in your application's UI, or a combination of both.

Chat messages

Recall.ai provides the Send Chat Message endpoint to send chat messages from a bot while it's in the call.

This can be an effective way to let your user know that they need to update their recording settings if the bot is unable to record.

Here's what this looks like in practice:

1. When a bot is denied recording privileges, you will receive a recording_permission_denied Bot Status Change Event
2. Since this can happen due to a legitimate denial from the host, you should check if the sub_code is a code related to Zoom settings specifically (in other words, one of: zoom_local_recording_disabled, zoom_local_recording_request_disabled, or zoom_local_recording_request_disabled_by_host)
3. If true, have the bot Send a Chat Message, providing a link to a help document:

   // POST /api/v1/bot/{id}/send_chat_message/
   {
     "message": "I am unable to record due to the host's recording settings. Please see this help article for instructions on how to resolve this: {HELP_DOC_URL}"
   }
   

In your app UI

Another great way to let your users know why a bot was unable to record is through an error message in your app.

For example, if a bot is unable to record due to their recording settings, we recommend surfacing this to your user and providing them with instructions on how to resolve the issue (for instance, by linking to a help article).

In this example, you could have the button link to a help article, or pop open a modal explaining how to check their Zoom recording settings.