Recording Preferences & Bot Deduplication
Configure which synced calendar meetings are recorded and prevent duplicate bots from joining the same meeting with Calendar V1.
Calendar meetings do not get recorded by defaultSee more in the Recording Preferences section below
Recording Prerequisites
Regardless of meeting preferences or manual recording overrides, a meeting must pass the following criteria in order to be recorded:
- Must contain a valid meeting link.
- Must have a both a start and end time (whole day events in are not supported).
- Must not be cancelled and cannot have already ended.
Manual Overrides
If a meeting passes Recording Prerequisites, the following conditions are applicable based on its override_should_record field value.
null: This is the default value. In this case, this field is ignored and Recording Preferences apply.true: The calendar meeting will be recorded, regardless of other preferences being applicable or not.false: The calendar meeting will not be recorded, regardless of other preferences being applicable or not.
Recording Preferences
Calendar meetings do not get recorded by default.
Auto-recording behavior for synced calendar meetings is determined by the configured recording preferences. These preferences can be modified using the Update Recording Preferences endpoint.
A recording preference is applicable to a meeting only if:
- Meeting passes Recording Prerequisites.
- Meeting has
override_should_recordfield value asnull. - Preference value is
true. (Note: Incase offalsethe preference is ignored rather than its negative being applicable)
Recording preferences behaviorOnly recording preference that are set to
truewill be evaluated. If all evaluated conditions are met, the meeting will be recorded.
Below is a list of supported preferences:
record_non_host: Meeting will be recorded only if the connected account is not the host of the meeting.record_external: Meeting will be recorded only if it has at least 1 external attendee.record_internal: Meeting will be recorded only if it has no external attendee.record_recurring: Meeting will be recorded only if it is a recurring meeting.
An external attendee is defined as a participant having a different email domain than the email domain of the meeting host.
Additional preference filters(Note: These settings act as additional filters on meetings that pass the above preference rules):
record_confirmed: Meeting will only be recorded if the calendar account has "accepted" it.record_only_host: Meeting will only be recorded if the calendar account is the host of the meeting.
Common use cases and recording preference combinations
Because recording preferences build on top of each other, we recommend not exposing them directly to end users. Instead, define a set of preference objects for the use cases your application supports, then apply the appropriate object to each user.
Below are several common use cases and their corresponding preference objects. Any preference key you want omitted from an object should be set to false.
Record all meetings
{
"record_non_host": false,
"record_recurring": false,
"record_external": true,
"record_internal": true,
"record_confirmed": false,
"record_only_host": false
}Record only internal meetings
{
"record_non_host": false,
"record_recurring": false,
"record_external": false,
"record_internal": true,
"record_confirmed": false,
"record_only_host": false,
}Record only external meetings
{
"record_non_host": false,
"record_recurring": false,
"record_external": true,
"record_internal": false,
"record_confirmed": false,
"record_only_host": false,
}Record only meetings where connected account is the host (both internal + external)
{
"record_non_host": false,
"record_recurring": false,
"record_external": true,
"record_internal": true,
"record_confirmed": false,
"record_only_host": true,
}Record only meetings where connected account has accepted the invite (both internal + external)
{
"record_non_host": false,
"record_recurring": false,
"record_external": true,
"record_internal": true,
"record_confirmed": true,
"record_only_host": false,
}For use cases not listed above, contact us in Slack to confirm the appropriate combination of recording preferences.
Customizing the Name of Your Calendar Bots
The calendar bot name can be configured for each user by updating the bot_name preference field. Changes may take a few minutes to propagate to all bots already scheduled for that user.
Bot Deduplication
By default, Recall automatically deduplicates bots across connected calendars within the same Recall workspace, ensuring that only one bot is sent to a meeting. The example below illustrates this behavior:
Bot deduplication exampleLet’s say we have:
- Users U1 & U2 [email protected] & [email protected]
- Apps A1 & A2 using Recall’s calendar integration via their accounts [email protected] & [email protected] (both have de-duplication turned on their accounts)
- Both U1 & U2 connect their calendars in A1 & A2, and have a shared meeting M1 which needs to be auto-recorded.
How many bots should join the meeting M1 ?
1 - ❌ (This would mean both A1 & A2 have access to shared bot data which is incorrect)
2 - ✅ (One accessible to A1, One accessible to A2)
4 - ❌ (If de-duplication was turned off there would be 4 bots joining the call, U1A1, U1A2, U2A1, U2A2)
When a bot is deduplicated across multiple meetings, the calendar_meetings array includes a reference to each associated calendar meeting.
Custom de-deduplication
The Calendar V1 APIs do not support custom bot deduplication logic. To define your own deduplication behavior, we recommend integrating with the Calendar V2 APIs.
Deduplication Constraints
Deduplication only occurs when users’ connected calendars use the same calendar platform. Recall sends one bot per platform represented among the meeting participants.
For example:
- If all participants use Google Calendar, Recall sends one bot.
- If participants use both Google Calendar and Microsoft Outlook, Recall sends two bots—one for each platform.
Updated about 1 hour ago
