Granola data integration

A read-only API key integration that syncs Granola meeting notes and transcripts into Rippit on a schedule. For what applies to every integration, see how data integrations work. For the security model, see Data integration security. This page covers the data integration, which imports your Granola notes into Rippit. To let the Rippit agent search Granola live during a chat instead, see the Granola MCP server.

Connection summary


Authorization	Granola API key, sent as `Authorization: Bearer <key>`
Key format	Starts with `grn_`. Any other value is rejected before it reaches Granola
Granola plan	Business or Enterprise, to create an API key
Scope parameter	None
Writes to Granola	None. Every call is a `GET`
Credentials shared with Rippit	The API key. Rippit stores it and uses it for every sync
Credential check	The key is tested against Granola before the connection is saved. A rejected key creates no connection, and Rippit does not keep the key
Connection identity	The workspace name you enter. Granola’s API returns no workspace or account ID
Required Rippit role	Workspace admin
API base	`https://public-api.granola.ai`
API version	`v1`, in the path
Sync method	Scheduled polling
Attachments and audio	None requested. Only note text and transcript text
Maximum historical backfill	All time by default, with no limit on the number of notes
Adding older history	After the first import finishes, the integration’s Overview tab in Connections → Integrations offers older ranges before its start date, with the same presets as setup. Add history back to … names the date the chosen range reaches and imports it. All time reaches your first note, or January 1, 2023 when Rippit cannot find it. The table stays ready meanwhile
Field selection limit	150 fields at setup, plus Rippit’s standard columns. You can add more later with Add new columns on the table

Before you connect

Rippit asks for two values: a Granola API key and a name for the workspace. Creating a key needs a Granola Business or Enterprise plan, and the key starts with grn_. The workspace name labels the connection in Rippit, because Granola’s API returns no workspace or account ID.

Data handling

Question	Answer
Is note content ingested, or only metadata?	Full content: Granola’s AI summary, the note’s private notes, and the full transcript
Are private notes ingested?	Yes. They are stored as an internal comment, separate from the summary and the transcript, and as the Private notes field, which is not selected by default
Are attachments or audio stored?	No. No file or audio endpoint is called
Can Rippit modify Granola?	No. No write code path exists
Is data used to train models?	No. Rippit does not train any AI models. Your data is used for inference only

What a note becomes in Rippit

Each Granola note becomes one conversation in Rippit.

Rippit record	Content
Subject	The note title
Agent	The note owner, by email. The owner is also added to your agent list
Fields	Owner name, attendee emails, folder names, the note’s Granola URL, summary text, private notes text, and speaker capture
Default selected fields	Title, owner, attendee emails, summary, commenters, first commenter, and last commenter
Summary comment	Granola’s AI summary, timestamped at the note’s creation so it sits above the transcript
Internal comment	The note’s private notes, when present, timestamped the same way
Transcript comments	The transcript, one comment per speaker turn

Transcript lines are merged into speaker turns. Consecutive lines from one speaker join the same turn until there is a pause of more than 3 seconds or the turn reaches 1,000 characters. Lines Granola attributes to the note owner carry the owner’s name or email. Other speakers carry the name Granola identified. When Granola has no name and the note has exactly one attendee besides the owner, that attendee’s name or email is used. Otherwise the line carries Granola’s anonymous speaker label, when there is one.

Why is the other speaker missing or unnamed?

Rippit names speakers from what Granola recorded. Two recording setups lose the other side of the call:

What you see	Cause
Every line carries the note owner’s name	Granola captured only the microphone, so it attributed the whole recording to the owner. In-person meetings always look like this, because there is no call audio to capture, and no setting changes it. On a call, the other side was heard through the owner’s mic, not captured as system audio
The other side is unnamed	Granola captured system audio but did not name the speaker, and the note has no single attendee besides the owner to fall back on

The Speaker capture field flags each note as Owner only, Other side unnamed, Both sides named, or No transcript, so you can find recorders whose setup loses the other side. This is set per recording, on each recorder’s Granola app. To get both sides with names on new call recordings, follow Granola’s speaker attribution guide:

Record in the Granola desktop app on macOS or Windows.
Join from the Zoom or Microsoft Teams desktop app. For Google Meet, use Chrome with Accessibility access for Granola, or the Granola Chrome extension.
Turn on speaker tags. On macOS they need Accessibility permission, which admins can pre-grant through MDM.
Connect a calendar so 1:1 meetings carry the other attendee, which Rippit uses when Granola has no name.

Existing notes keep the speakers they were recorded with. A re-sync reads the same transcript from Granola and does not add names or split a mic-only recording into two speakers. The “Chat with meeting transcript” link Granola appends to each summary is removed. Links from Rippit to a note open the note’s own Granola URL.

API endpoints

Authentication

Purpose	Endpoint	Method
Credential check when you connect, and before each sync	`/v1/notes?page_size=1`	GET

Notes

Object	Endpoint	Method
Note discovery	`/v1/notes?updated_after=<window start>&created_before=<window end>&page_size=30`	GET
Note content and transcript	`/v1/notes/<id>?include=transcript`	GET
Note without transcript, when Granola answers `413` because the transcript is too large to inline	`/v1/notes/<id>`	GET
Transcript, paged, for those notes	`/v1/notes/<id>/transcript?page_size=100`	GET
Field discovery, a sample of 5 notes, at most every 6 hours	`/v1/notes?page_size=5`, then `/v1/notes/<id>?include=transcript` for each	GET

Notes are read in two phases, which is why /v1/notes and /v1/notes/<id> both appear. Discovery. /v1/notes returns only each note’s ID, title, owner, and timestamps. Granola has no updated_before filter, so each window is bounded by created_before, which keeps a backfill from listing the same notes in every window. updated_after still catches edits to older notes. Granola pages by cursor, and Rippit repeats the original filters on every page. Content. Each listed note is then fetched individually at /v1/notes/<id>?include=transcript, 5 concurrent. This is the call that returns the summary, private notes, attendees, folders, and transcript. A note that returns 404, because it was deleted after it was listed, is skipped. No other Granola object is listed or swept. Owner, attendees, and folders come from the note record itself. No endpoint for deleted notes is called.

Sync behavior


Note discovery	Windowed on `updated_after`, bounded by `created_before`, 30 per page, cursor pagination
Window width	30 days, one window at a time
Trailing buffer	Each window closes 5 minutes behind the current time
Content fetch	Per note by ID, 5 concurrent
Daily re-sweep	The last 24 hours are listed again once a day, because a note appears in the list only after Granola generates its AI summary
Update handling	An edited note is listed again and refetched. A note version already fetched in the same run is not fetched twice

Rate limiting

Every request, retries included, starts at least 200 ms after the previous one, so a sync sends at most 5 requests per second
A backfill makes one content request per note, on top of the discovery pages

Getting Started

Bring your data together

Ask Rippit and build

Build Pipelines

Connect your AI Assistant

Use cases

Reference