Skip to content
Skip to main content

Troubleshoot Notetaker

Last updated:

When a Notetaker doesn’t behave the way you expected, the history endpoint is the first place to look. It returns every state change for a single bot in order, so you can see whether it was scheduled, whether it joined, when it left, and whether media was produced. This page covers how to read that timeline and the four problems it most often explains.

Troubleshoot a Notetaker from its history

Start with the Notetaker's history, then match the state and meeting_state values to a symptom. Each side card shows the value to look for and what to do.
Diagram as text
  • Your app: Get the Notetaker's history: GET /v3/notetakers/{notetaker_id}/history or the grant-based version. Newest event first.
  • Check that it joined: Look for a notetaker.meeting_state event with recording_active.
    • failed_entry: no_response or entry_denied → Never joined the meeting: Not admitted within about 10 minutes, or denied. Ask the host to admit it.
    • failed_entry: link or access reason → Couldn't open the meeting: bad_meeting_link, meeting_passcode_required, or host_sign_in_required. Fix the link or allow guests.
  • Check why it left: Read meeting_state on the disconnected event. meeting_ended is a normal exit. (Joined)
    • no_activity → Left after silence: Default is 300 seconds of silence. Raise leave_after_silence_seconds.
    • no_participants or kicked → Left the meeting early: Everyone else left, or a participant removed the bot.
  • Check the media: Look for a notetaker.media event after the bot leaves. (Left the meeting)
    • processing → Media still processing: Wait for the available notification. The media endpoint returns 404 until then.
    • media_error → Media never arrived: Processing failed. Share the full history payload with Nylas Support.
  • Check for setting changes: Compare the notetaker.updated events, oldest to newest. (Wrong time, link, or settings)
    • Calendar event changed → Calendar sync updated it: Changed events are re-checked against calendar rules. Events that no longer match lose their Notetaker.
    • Configuration changed → Settings resolved at dispatch: Configuration edits apply until dispatch. Inspect sources with config_details=true.

The history endpoints return an ordered timeline of everything that happened to one bot. There’s one for each Notetaker form:

Call the endpoint with your API key and the Notetaker ID from an API response or webhook notification. The response holds one entry per event, up to 5 event types, and each entry is a snapshot of the whole Notetaker at that moment rather than a diff.

The data.events array is ordered most recent first. Each item has three fields:

  • created_at: When the event was recorded (Unix timestamp, in seconds).
  • event_type: The kind of change that occurred: notetaker.created, notetaker.updated, notetaker.meeting_state, notetaker.media, or notetaker.deleted.
  • data: The Notetaker payload at that moment, including state, meeting_state, and (for media events) a media object. History entries use the same shape as webhook payloads, so settings appear under the legacy name meeting_settings even when you sent them as notetaker_settings.

Notetaker is always a non-signed-in user on the meeting platform. If the meeting is limited to organization members, or the host has a waiting room, someone has to admit the bot. If nobody does within about 10 minutes after the bot asks to join, the bot gives up and Nylas sends a notetaker.meeting_state webhook with status set to failed_entry. To tell the host while the meeting is still running, see Tell the host when Notetaker can’t join.

To confirm what happened, check the history:

  • Look for a notetaker.created event to confirm the bot was scheduled at all.
  • Check the later notetaker.meeting_state events. Repeated connecting or a final failed_entry value points to a join or lobby issue on the meeting provider’s side.
  • If there are no notetaker.meeting_state events, verify that the meeting link is valid and the join_time is correct.
  • If the request itself returned 400 Bad Request with the message notetaker dispatch is disabled, dispatch is paused for that grant, workspace, or application.

Notetaker left the meeting earlier than expected

Section titled “Notetaker left the meeting earlier than expected”

By default a Notetaker leaves after 300 seconds of continuous silence. It also leaves when the meeting ends, when the other participants leave, when a participant removes it, or when you call the leave endpoint. The history tells you which one it was.

  • Find the last notetaker.meeting_state event and read data.meeting_state. meeting_ended means the call closed, no_activity means silence detection ended the recording, no_participants means the other participants left, kicked means a participant removed the bot, and api_request means your app called the leave endpoint.
  • Compare that event’s created_at to the meeting’s expected duration. A gap that matches your leave_after_silence_seconds value usually means silence detection ended the recording.

Nylas needs a few minutes after the bot leaves to process the recording, and the download URLs in the resulting webhook expire after 60 minutes. Most “missing media” reports are one of those two, and the history confirms which.

  • Confirm there’s at least one notetaker.meeting_state event with the bot in an attending state and meeting_state set to recording_active. Without it, nothing was recorded.
  • Look for a notetaker.media event. If it’s present, inspect data.media for the recording, transcript, summary, and action_items entries and check whether your app downloaded them before the URLs expired. Current URLs come from the media endpoint.
  • If the last notetaker.media event has state set to media_error, processing failed. Share the full history payload with Nylas Support.

The media endpoint’s status code also narrows it down. A 404 means the media isn’t ready: the bot hasn’t left the meeting yet, the files are still processing, or processing failed with media_error. Ready media shows as the available state in webhooks and history, and as media_available in a Get Notetaker response. A 410 with the body media deleted means the retention window passed or someone deleted the Notetaker, and the files are gone. A 410 with the body media unavailable means the bot never got into the meeting (failed_entry).

Nylas resolves settings at dispatch, so a Notetaker can use different defaults if a parent configuration changes after scheduling but before dispatch. After dispatch, the run keeps its captured settings. Use config_details=true on the individual Notetaker GET to inspect setting sources and dependency normalization.

  • Review each notetaker.updated event for changes to join_time, meeting_link, or meeting_settings. Calendar sync produces these when an event moves or its details change.
  • Because events are most recent first, step backwards through the array to reconstruct how the Notetaker’s settings evolved. The meeting_settings object in each snapshot is the resolved result of the configuration hierarchy at that moment, not just what you passed inline.