A Recording represents a meeting recap in Fellow, and associated metadata. Each Recording is associated with a Note, and can contain information such as:

• Diarized and timestamped transcripts
• Event times (scheduled start/end, and recording start/end)
• Virtual call URL (Google Meet, Zoom, MS Teams URLs)
• Event identifier to match the calendar event to 3rd party Calendar APIs

Access Rules

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

• They are an attendee of the event which was recorded.
• The recap was explicitly shared with them by an attendee of the event.
• The notes series of which the recap is a part of was explicitly shared with them.
• They are in a channel where the recap was published by an attendee of the event.

Key Concepts

Transcripts

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

POST /api/v1/recordings
Authorization: ApiKey YOUR_API_KEY

{
  "include": {
    "transcript": true
  }
}

When the transcript field is included, a APITranscript object will be returned containing the detected language of the transcript, and a list of speech segments including the speaker and the start/end timestamps in relation to the start of the recording:

{
  "language_code": "en-US",
  "speech_segments": [
    {
      "speaker": "Anna",
      "text": "Welcome everyone to today's meeting",
      "start_time": 0.0,
      "end_time": 3.2
    }
  ]
}

Notes

Each Recording has a related Note object, whose identifier is present in the note_id in the Recording object. These Note objects, also accessible through the API and respecting the same access conditions as the Recordings, contain more information about the recap (such as the written agenda content, and the list of meeting attendees from the related calendar event).

Filtering

The API supports several filters to help you find specific Recordings. 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.