Fireflies Sensor

What it ingests

Meeting transcripts from the Fireflies.ai GraphQL API (https://api.fireflies.ai/graphql). One recorded meeting becomes:

Fireflies data	Ontology entity / edge	Hydration
The meeting	Meeting, named <title> (<start time>)	deterministic
The transcript (sentences)	CreativeWork (source_type: transcript), Meeting PRODUCED it	deterministic
Calendar attendees and speakers who were in the call	Person via identity hints, ATTENDED the Meeting	deterministic
Calendar attendees with no sign they joined	Person, INVITED_TO the Meeting	deterministic
summary.action_items	ActionItem, Meeting PRODUCED it; Person ASSIGNED_TO it when Fireflies grouped it under an attendee's name	deterministic
Bullets under a Decisions heading in the summary	Decision, Meeting DECIDED_ON it	deterministic
The calendar event Fireflies recorded	the existing calendar Event gets RELATED_TO the Meeting	deterministic
Topics, projects, organizations, technologies, and decisions the summary did not list	from the transcript	LLM

The signal is transcript. Every row above is a binding you can turn off from the source's bindings.

Same graph as the other notetakers. Fireflies uses the mapping Granola introduced, so a meeting looks the same in the graph whichever notetaker recorded it.

Action items keep their owners. Fireflies groups action items under the name of the person who owns them. When that name is an attendee's (full name, a first name no other attendee shares, or their email), the item is linked to that Person. Items under no name, or under a heading such as "Unassigned", are kept without an owner.

Who attended. Fireflies lists everyone on the calendar invite, whether or not they joined. A calendar attendee counts as having attended only when they spoke: their name, or their email's local part (dana.smith@… for "Dana Smith"), matches a transcript speaker. Speakers who match no one on the invite are added under the name the transcript gives them. Generic labels (Speaker 2) and the Fireflies bot are never people.

Merged with your calendar. Fireflies records the calendar event id on each meeting. When a Google Calendar or Outlook Calendar source has already ingested that event, the Meeting is linked to it (Event RELATED_TO Meeting), the join Google Meet recordings use. There is no fuzzy title or time match.

Each meeting is stored once, in full, in sensor_events.content: Fireflies' overview, shorthand notes, and action items, then the speaker-tagged transcript. Secrets spoken in a meeting (API keys, tokens, private-key blocks) are redacted before storage. Audio and video links, analytics, and AI app outputs are not requested.

Credential

References a fireflies_api_key credential by id. The secret is a Fireflies API key, sent as Authorization: Bearer <key>.

curl -sS -X POST https://your-corveil-host/api/credentials \
  -H "Authorization: Bearer <admin>" -H "Content-Type: application/json" \
  -d '{"type":"fireflies_api_key","name":"acme-fireflies","secret":"<api key>"}'

Each Fireflies user has one API key. The sensor reads the meetings that user can see: meetings they recorded or attended, and meetings shared with them. To cover a team, use the key of a user who has access to the team's meetings, or add one source per user.

Config fields

Key	Required	Notes
channel_id	no	A Fireflies channel id. Ingests only meetings in that channel. Blank reads every meeting the key's user can see.

A malformed id is rejected when you save the source.

There is no default_entity_type. This source emits several primary types (Meeting, transcript, decisions, action items), so one override would mistype the rest.

Provider-side setup

1. Sign in to app.fireflies.ai as the user whose meetings Corveil should read.
2. Open Settings → Developer settings (older workspaces: Integrations → Fireflies API).
3. Copy the API key. Store only the key value, not Bearer ….
4. Optional: to limit ingest to one channel, copy the channel's id from Fireflies and set channel_id.

No webhooks, OAuth app, or admin consent are needed.

Wire-up

POST /api/sensors

{
  "sensor_type": "fireflies",
  "name": "Acme Fireflies",
  "config": {},
  "credentials": { "fireflies_credential": "<fireflies_api_key credential id>" }
}

Verify

Run Test connection. It reads the key's own user, so a revoked or mistyped key fails at save rather than on the first poll.

Once polling, the per-poll log shows listed, events, already_ingested, and pending_summary. In the ontology, look for Meeting entities with notetaker: fireflies. Each one's neighborhood should hold its attendees, its transcript, its action items, and its calendar Event when the calendar source has that event.

How incremental sync works

• The first poll seeds a watermark and ingests nothing. History comes from the one-time backfill (SENSOR_BACKFILL_SINCE, default 72 hours), which reads meetings by date.
• Fireflies filters only on the meeting date, and lists a meeting only after it is transcribed. So each poll lists the 24 hours before the last watermark, with light fields only. The cursor remembers which meetings in that window were already ingested, so they are not downloaded again.
• Meetings still being summarized wait. A live meeting, or one whose AI summary is still processing, is left for a later poll. After 6 hours the transcript is ingested without the summary.
• A busy window is never skipped. One poll lists at most 500 meetings and downloads at most 25. Anything left over is picked up by the next poll, and the watermark does not move past it. A backfill that hits its ceiling fails and is retried.
• Deletes. A meeting that is gone by the time it is fetched is skipped. Entities from earlier ingests are not removed.
• Rate limits. Fireflies allows 30 requests a minute and 500 a day on Free, 60 a minute and 5,000 a day on Pro, and 60 a minute per paid seat with no daily cap on Business and Enterprise. The budget is shared with every other integration on the same key. The sensor spaces its requests about 2 seconds apart. On a 429 it waits for Retry-After and retries up to 3 times. When the wait is longer than a minute (the daily cap), it stops at once. Meetings already downloaded in that poll are kept, and the next poll continues from there. A backfill that hits the cap after downloading some meetings keeps them and completes, so polling can start; see the known limits.

Known limits

• Plan. On Free and Pro, the daily request cap limits how many meetings a day can be ingested. Business or Enterprise is recommended for a team.
• A backfill cut short by the daily cap is not resumed. The meetings it downloaded are kept, and the first polls cover the last 24 hours of the window. Older meetings it did not reach are skipped; the log line backfill rate limited reports how many were listed and how many were kept.
• Edits after ingest are not picked up by polling. Fireflies has no "updated" timestamp, so a meeting is downloaded once. A renamed meeting or a regenerated summary only reaches Corveil through a later backfill.
• Late transcripts. A meeting that appears in Fireflies more than 24 hours after its start date, while polling is running, is missed. A backfill covering that date picks it up.
• Speakers. Fireflies names speakers as it identified them. An unidentified speaker (Speaker 2) is kept in the transcript but is not a Person.
• Calendar merge needs the calendar source. For Outlook, Fireflies records the iCalUID, which may not match the event id Outlook Calendar stores, so Outlook meetings may not link.
• Not included: webhooks, audio and video, analytics, AI app outputs, channels as entities, and team-wide reads by an admin key on other users' behalf.