Pause Notetaker dispatch

Sometimes you need Notetakers to stop joining meetings for a while: a user hit their monthly recording quota, a customer paused their subscription, or your app enforces per-organization usage caps. Deleting calendar rules and cancelling scheduled Notetakers works, but then you have to rebuild all of it when the pause ends.

Pausing dispatch (also called dispatch suppression) solves this with one field. Set dispatch_disabled_until on a Notetaker configuration and Nylas stops sending bots to meetings until that timestamp passes, while calendar sync rules, scheduled Notetakers, and all recording settings stay exactly where they are. Clear the field (or let it expire) and dispatch resumes.

How pausing dispatch works

dispatch_disabled_until is an RFC 3339 timestamp on a configuration. While it’s in the future, Nylas doesn’t dispatch any Notetaker governed by that configuration: immediate join requests are rejected, and scheduled Notetakers stay scheduled without joining. The field has three states:

dispatch_disabled_until	Effect
null (or never set)	Dispatch works normally.
Future timestamp	Dispatch is paused until that instant.
Past timestamp	The pause has expired; dispatch works normally.

You can set the field at three scopes: application, workspace, and grant. If a pause is active at any of those scopes, the Notetaker doesn’t dispatch. A workspace can’t resume itself while the application is paused, and a grant can’t override its workspace. This differs from notetaker_settings, where the most specific value wins. Calendar, event, and per-notetaker configurations don’t accept the field.

A pause only affects dispatch. It doesn’t stop a bot that’s already connecting or in a meeting, and it doesn’t pause calendar sync. To remove an active bot, use the leave or cancel endpoints.

Pause Notetakers for one user

Per-user pauses use a grant configuration, a policy-only configuration whose config_id is the grant ID. Create it with a POST /v3/notetakers/configs request that passes grant_id and dispatch_disabled_until. This is the tool for usage caps: when a user hits their monthly quota, pause their grant until the next billing period.

curl --request POST \
  --url 'https://api.us.nylas.com/v3/notetakers/configs' \
  --header 'Authorization: Bearer <NYLAS_API_KEY>' \
  --header 'Content-Type: application/json' \
  --data '{
    "grant_id": "<NYLAS_GRANT_ID>",
    "dispatch_disabled_until": "2026-09-01T00:00:00Z"
  }'

Grant configurations carry policy only. They accept dispatch_disabled_until and nothing else; requests that include notetaker_settings or deduplication_policy return 400 Bad Request. They also never contribute settings, so the user’s Notetakers keep resolving their display name, recording, and transcription options from the workspace and application levels as usual.

Each grant can have one configuration. A second POST for the same grant returns 409 Conflict; use PATCH /v3/notetakers/configs/<NYLAS_GRANT_ID> to change the timestamp after that.

Pause a workspace or your whole application

Application and workspace configurations accept dispatch_disabled_until alongside their normal settings, so pausing a whole customer or your entire app is a single PATCH to a configuration you probably already have. The pause applies to every dispatch decision made after the update.

curl --request PATCH \
  --url 'https://api.us.nylas.com/v3/notetakers/configs/<CONFIG_ID>' \
  --header 'Authorization: Bearer <NYLAS_API_KEY>' \
  --header 'Content-Type: application/json' \
  --data '{
    "dispatch_disabled_until": "2026-09-01T00:00:00Z"
  }'

If you don’t have an application or workspace configuration yet, include dispatch_disabled_until on the POST that creates one. See Notetaker configurations for how the two scopes differ and how workspaces group grants.

What happens while dispatch is paused

While a pause is active, requests behave differently depending on whether the Notetaker would join now or later. Existing scheduled records and calendar rules are preserved in both cases; nothing is deleted or cancelled.

• Immediate joins: a POST /v3/notetakers or POST /v3/grants/<NYLAS_GRANT_ID>/notetakers request without a future join_time returns 400 Bad Request with the message “notetaker dispatch is disabled”. No Notetaker is created and no webhook fires. Your app must tell the user why the bot didn’t join.
• Scheduled Notetakers: they stay in the scheduled state and simply don’t join when their meeting starts. Nylas doesn’t send an error, a status webhook, or a state change, because from the API’s perspective nothing about the Notetaker changed.
• Calendar sync: calendar sync keeps creating and updating scheduled Notetakers for new and changed events. Those records accumulate normally and dispatch again once the pause ends.
• Deduplication: if deduplication would combine several users’ bots into one, paused users are left out. The shared bot joins for the remaining users only, and paused users receive no media or webhooks from it.
• Active bots: a bot that’s already connecting or attending is unaffected. Pausing doesn’t recall it.

Resume dispatch

Resuming is the reverse of pausing: send dispatch_disabled_until: null on a PATCH, or just wait for the timestamp to pass. Either way, calendar rules and scheduled Notetakers you created before the pause start dispatching again with their original settings, and there’s nothing to rebuild.

curl --request PATCH \
  --url 'https://api.us.nylas.com/v3/notetakers/configs/<CONFIG_ID>' \
  --header 'Authorization: Bearer <NYLAS_API_KEY>' \
  --header 'Content-Type: application/json' \
  --data '{
    "dispatch_disabled_until": null
  }'

Omitting the field on a PATCH leaves the current value unchanged, so you can update other configuration fields without touching an active pause. Configuration changes are versioned; add ?include=history to a GET /v3/notetakers/configs/<CONFIG_ID> request to audit when pauses were set and cleared.

One behavior to plan around: meetings whose join time passed during the pause don’t join late. If a user’s 10:00 meeting was skipped because their grant was paused, resuming at 10:15 doesn’t send a bot into that meeting; only meetings that haven’t started yet dispatch after the resume. The exception is rescheduling: if the skipped meeting’s event moves to a new future time (or you update a manually scheduled Notetaker’s join_time), the Notetaker becomes eligible again and dispatches normally if no pause is active.

What’s next

• Notetaker configurations for the configuration hierarchy and how settings resolve.
• Notetaker calendar sync for the sync rules that keep scheduling Notetakers during a pause.
• Notetaker deduplication for how shared bots behave when some users are paused.
• Create a Notetaker configuration in the API reference.