A Note represents a meeting agenda in Fellow, and associated metadata. Notes may be associated with multiple Recordings, and can contain information such as:

• Event times (scheduled start/end)
• Virtual call URL (Google Meet, Zoom, MS Teams URLs)
• Event identifier to match the calendar event to 3rd party Calendar APIs
• Event attendees (email addresses)
• Agenda/Note content

Access Rules

The same access rules that apply in Fellow, apply through the API: the only Notes available to an API Key are the same ones that are available to the API Key's owner in the interface. Notes may be accessible to someone through a variety of methods:

• They are an attendee of the event related to the Note.
• The Note, or Note series, was explicitly shared with them by an attendee of the event.
• They are in a channel where the Note was published by an attendee of the event.

Key Concepts

Note Content

Fellow Notes are built using a structured block system (action items, talking points, headers, bullet points, etc.) rather than plain text. The content_markdown field provides a human-readable markdown representation of all the note's content blocks, making it easy to export, display, or process note content in external systems without needing to understand Fellow's internal block structure.

Notes can be quite large, and are not included in API responses by default when retrieving a list of Notes. These must be explicitly requested using the include parameter:

POST /api/v1/notes
Authorization: ApiKey YOUR_API_KEY

{
  "include": {
    "content_markdown": true
  }
}

When the content_markdown is included, the markdown version of the structured note will be included in the response:

{
  "page_info": {
    "cursor": null,
    "page_size": 20
  },
  "data": [
    {
      "id": "G4GEKZe4t2",
      "title": "Weekly Team Standup",
      "created_at": "2024-01-15T10:00:00Z",
      "event_start": "2024-01-15T14:00:00Z",
      "content_markdown": "# Project Updates\n\n* Review Q1 roadmap priorities\n* Discuss resource allocation for new features\n\n## Action Items\n\n* Action Item: Complete documentation by Friday (Due: 2024-01-19) @john.doe\n* Action Item: Schedule design review meeting @sarah.smith\n* Action Item: Update deployment pipeline configuration\n\n## Discussion Topics\n\n* Database migration strategy\n  * Evaluate downtime requirements\n  * Plan rollback procedures\n* Performance optimization\n  * Review current bottlenecks\n  * Prioritize fixes for next sprint\n\n## Decisions Made\n\n* Move forward with PostgreSQL upgrade\n* Implement feature flags for gradual rollout"
    }
  ]
}

Event Attendees

Just like the Note content, the list of event_attendees is not included by default when getting a list of Notes and must be explicitly requested.

When returned, the event_attendees is a list of the email addresses that were invited to the related calendar event for the Note, if any. There are some things to keep in mind when looking at this data:

• The list of event's attendees is not necessarily the same as the list of people who have access to a given resources in Fellow. Someone may have received access to a Note/Recording by having it shared with them, without being invited to the original event.
• The list of email addresses is not necessarily the direct list of email addresses that received the event invitation. For example, if a group email was invited to the event ([email protected]) that email address will not be broken down into the list of individual email addresses that are in that group.
• This list includes external email addresses if relevant. It also includes email addresses of internal attendees, even if they do not have a Fellow account.

Because of this, the list of event_attendees email addresses should not be used to infer whether someone has access to a resource in Fellow.

Recordings

Each Note may have related Recording object, whose identifier is present in the recording_ids field in the Note object. These Recording objects, also accessible through the API and respecting the same access conditions as the Notes, contain information related to any recordings that were made for the Note, such as the transcript. A Note may have multiple Recordings because a recording may have been started and stopped throughout a meeting multiple times (a Recording however, may only be related to a single Note).

Filtering

The API supports several filters to help you find specific Notes. All filters are optional and can be combined to narrow your search results.

Example valid Date/DateTime formats:

• 2025-12-31
• 2025-12-31T23:59:59Z
• 2025-12-31T12:00:00-05:00

Results that are returned will meet all of the criteria in the conditions. In the example below, all Recordings that were created after March 25th 2024 AND contain the word "demo" in the title will be returned.

{
  "filters": {
    "created_at_start": "2024-03-25",
    "title": "demo"
  }
}

Why POST for List Operations?

Fellow’s list endpoints accept POST requests (even though they are read‑only) because that method is the safest and most practical way to send rich, filterable queries:

• Keeps sensitive filters out of URLs: Pagination tokens, event identifiers, or search strings are sent in the request body rather than the query string, so they won’t appear in browser history, referrer headers, or easily copied links. Most edge proxies and access logs record only the request line, not the body, which lowers the risk of accidental exposure.
• Handles complex JSON cleanly: Our filtering and pagination schema is a nested JSON object that would be awkward—and in many cases exceed length limits—if encoded into a URL. A body payload keeps the request readable and avoids edge‑case encoding issues.
• Avoids unintended caching: GET requests are often cached by default by browsers or intermediaries. Using POST signals that each request may be unique, so content is returned fresh and not from an outdated cache.

Using POST for complex “list” operations is a well‑established pattern for APIs that accept sensitive or deeply nested query criteria. Although it departs from the classic REST convention of GET‑for‑read, it provides a safer, more scalable approach for Fellow’s use case.