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.

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 10 minutes of the scheduled join time, the bot gives up and Nylas sends a notetaker.meeting_state webhook with status set to failed_entry.

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, and it also leaves when the meeting ends, 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, 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. Fresh URLs come from the media endpoint.
  • If there’s no notetaker.media event, processing failed. Share the full history payload with Nylas Support.

The media endpoint’s status code also narrows it down. A 404 means media is still processing, or the Notetaker never reached media_available. A 410 with the body media deleted means the retention window passed or someone deleted the Notetaker, and the files are gone.

Because settings are read when the bot joins rather than when it’s scheduled, a Notetaker can join with different values than the ones you sent if a configuration changed in between. The notetaker.updated events show exactly what changed and when.

  • 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.