# Pause Notetaker dispatch Source: https://developer.nylas.com/docs/v3/notetaker/dispatch-suppression/ 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](/docs/v3/notetaker/configurations/) 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](/docs/reference/api/notetaker/post-notetaker-leave/) or [cancel](/docs/reference/api/notetaker/cancel-notetaker/) 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`](/docs/reference/api/notetaker-configurations/create-notetaker-config/) 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. ```bash curl --request POST \ --url 'https://api.us.nylas.com/v3/notetakers/configs' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "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/`](/docs/reference/api/notetaker-configurations/update-notetaker-config/) 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. ```bash curl --request PATCH \ --url 'https://api.us.nylas.com/v3/notetakers/configs/' \ --header 'Authorization: Bearer ' \ --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](/docs/v3/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//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](/docs/v3/notetaker/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](/docs/v3/notetaker/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. ```bash curl --request PATCH \ --url 'https://api.us.nylas.com/v3/notetakers/configs/' \ --header 'Authorization: Bearer ' \ --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/`](/docs/reference/api/notetaker-configurations/get-notetaker-config/) 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](/docs/v3/notetaker/configurations/) for the configuration hierarchy and how settings resolve. - [Notetaker calendar sync](/docs/v3/notetaker/calendar-sync/) for the sync rules that keep scheduling Notetakers during a pause. - [Notetaker deduplication](/docs/v3/notetaker/deduplication/) for how shared bots behave when some users are paused. - [Create a Notetaker configuration](/docs/reference/api/notetaker-configurations/create-notetaker-config/) in the API reference.