I compared webhook payloads, events and signing on 5 AI notetakers: here's my pick for 2026

Every notetaker here can POST to a URL when a meeting is done. What differs is what lands in that request: Circleback, Fathom, tl;dv and Read AI can put the whole meeting in it, while Fireflies.ai sends an ID and leaves you to fetch the rest.

My pick is Circleback. You choose which outcomes go out (notes, action items, transcript, AI insights), every request is signed, and you can send past meetings on demand. I compared the five on payload depth, events, signing, retries, scope and plan, using each vendor's own docs.

My picks at a glance

• Circleback: best overall for a full, signed payload and control over which meetings send.
• Read AI: best when one admin-owned endpoint should receive every member's reports, with a meeting start event.
• Fathom: best when webhooks have to work on every plan.
• Fireflies.ai: best for fine-grained events and resends, if you will fetch content yourself.
• tl;dv: best when you want your own auth header and user, team or organization scope.

What a meeting webhook can carry

A webhook is either a notification (an event name and an ID, with the content fetched through the vendor's API) or a full payload that holds the content. Fireflies.ai sends notifications. Circleback, Fathom, tl;dv and Read AI can put content in the request.

Two details matter most: whether you can switch sections on or off, since a long transcript makes the request large (tl;dv puts it at roughly 1 to 2 KB per minute of speech), and what you can verify and dedupe on, meaning a signature header and an ID that stays stable across retries.

Webhook details for each notetaker

Circleback: pick the outcomes, sign every request

Circleback's webhook is a step inside an automation. Each request is a POST with a JSON body to one HTTPS URL.

• Events: One event, with no event-type field. It fires after each matching meeting's notes are ready, when an added tag makes a meeting match, and on manual runs for one or many past meetings.
• Payload: Always sent: id, name, createdAt, duration, url, recordingUrl, tags, icalUid and attendees (name, email). Sent only when you tick the outcome: notes in Markdown, action items (title, description, assignee, status pending or done), transcript (speaker, text, timestamp per segment) and AI insights keyed by insight name. recordingUrl expires after 24 hours and is empty when no recording was saved or it has passed retention.
• Signing and delivery: Every request carries an X-Signature header, an HMAC-SHA256 hex digest of the raw JSON body made with a per-step secret (whsec_...) that you can copy and rotate. Up to 10 attempts on any non-2xx response. Public HTTPS endpoints only, redirects refused, no custom headers.
• Scope: Automation conditions decide which meetings send: tags, meeting title, participants, invitee emails, invitee email domains and number of invitees. With no conditions, every meeting sends.
• Pricing: Pro is $15 per user per month billed annually ($18 monthly). Pricing page.
• Why I'd pick it: Notes, action items, transcript and insights can arrive in one request, with speaker and timestamp on every segment. Conditions plus manual runs let you back-fill, and a REST API with a Bearer key that any user can create covers the pull side.
• Limits: The webhook step is not available on Free. There is one event, sent after the notes are ready, so no earlier transcript-only event. Imported meetings never fire it on their own.

Fireflies.ai: three events, ID-only payload

Fireflies.ai replaced its old webhooks with Webhooks V2, which lets you subscribe to specific events.

• Events: meeting.transcribed (transcript ready), meeting.summarized (summary, action items and notes ready) and meeting.bot_joined. Subscribe to one or more. An optional "Resend when a meeting's notes change" setting sends the first two again, with a reprocessed_at field, when a transcript or summary changes.
• Payload: A notification only: event, timestamp in milliseconds, meeting_id, plus optional client_reference_id and reprocessed_at. The meeting ID is the transcript ID used across the Fireflies API, so you fetch the content with a second call. The timestamp changes on every retry, so order changes by reprocessed_at.
• Signing and delivery: An optional signing secret. When set, requests carry X-Hub-Signature, formatted sha256= plus the hex HMAC-SHA256 digest of the body. HTTPS to a public host, no redirects, 2xx within 30 seconds. Failed deliveries retry up to 5 times (30 seconds, 2 minutes, 10 minutes, 30 minutes, 2 hours) for connection failures, 429 and 5xx. Other 4xx responses, TLS errors and post-connect timeouts do not retry.
• Scope: Meetings you own. Team-wide webhooks are for the Enterprise tier with the Super Admin role.
• Why I'd pick it: The finest event split of the five, resends when content changes, and the most detailed retry schedule.
• Limits: Every meeting costs at least one more API call, and API limits start at 30 requests a minute and 500 a day on Free (60 and 5,000 on Pro). Signing depends on you setting a secret.

Fathom: full content, one event, all plans

Fathom sends meeting data to a URL you choose, and you decide which content rides along.

• Events: One: new meeting content ready, when a recording finalizes (the moment the summary email goes out). No post-call summary means no webhook. It fires once, does not fire again if the transcript, summary or visibility changes, and cannot be re-sent by hand.
• Payload: Meeting title, recording ID, URLs, scheduled and recording times, calendar invitees, who recorded it, transcript language and a shared_with field. Four content options, all off by default: include_transcript (speaker name, matched invitee email, text, HH:MM:SS timestamp), include_summary (Markdown), include_action_items (with assignee and playback URL) and include_crm_matches (only from a CRM you or your team linked).
• Signing and delivery: Three headers: webhook-id, webhook-timestamp and webhook-signature, an HMAC-SHA256 over the id, timestamp and raw body with a secret that starts whsec_. webhook-id stays the same on a retry, so you can dedupe on it. Non-2xx responses or timeouts may trigger retries, and Fathom publishes no schedule or attempt count. No custom headers.
• Scope: You set triggered_for when you create the webhook, with at least one value: my_recordings (your private recordings and ones you shared with individuals) or shared_external_recordings (shared with you by other users). Team plans add my_shared_with_team_recordings and shared_team_recordings. The payload does not say which user's key triggered it, so use a separate URL per user.
• Plan: Fathom says keys and webhooks are included on all plans. The two team scopes are for Team plans only.
• Why I'd pick it: Webhooks on every plan, with content in the request.
• Limits: One event, fired once, with no resend after edits. A webhook's ID comes back only at creation. If you add lookups, the REST API allows 60 calls in a 60-second window.

tl;dv: two events, your own auth headers

tl;dv sends two separate events, and you choose the scope.

• Events: MeetingReady (the meeting finished processing) and TranscriptReady (a transcript is available). Subscribe to one or both.
• Payload: MeetingReady carries the meeting ID, name, date, organizer, invitees and URL, and the API reference sample adds notes in Markdown. An opt-in "Include meeting transcript" box embeds the transcript (null when none is complete). TranscriptReady carries segments with speaker and start and end times, but no organizer or invitees.
• Signing and delivery: You add your own headers, such as an Authorization bearer token or an x-api-key, and tl;dv sends them with every request. HTTPS only. tl;dv waits at most 10 seconds for a response before retrying.
• Scope: User, team or organization. tl;dv's API reference says organization-wide automation requires Enterprise.
• Plan: The pricing page lists "MCP server, API & webhooks" on the Pro card, and the Business and Enterprise cards build on Pro. Pro is $18 per seat per month billed annually ($29 monthly), and Business is $29 annually ($39 monthly).
• Why I'd pick it: Custom headers, three scope levels and a separate transcript event.
• Limits: TranscriptReady has no organizer or invitees, so join on the meeting ID.

Read AI: user and workspace webhooks, full payload

Read AI pushes a meeting report to an HTTPS endpoint when it is ready, and you can push any report by hand. User and workspace webhooks share one payload schema and one signing method.

• Events: meeting_end fires when the report is generated after a meeting ends, normally once per report. Workspace webhooks can also fire meeting_start, a subset payload (session_id, trigger, title, start_time, owner, platform, platform_meeting_id, request_id) because no report exists yet. A manual push always sends meeting_end.
• Payload: session_id, trigger, title, start_time, end_time, participants (name, email), owner, summary, action_items, key_questions, topics, report_url, chapter_summaries, transcript, platform_meeting_id, platform and request_id. The transcript is speaker blocks with start and end times in Unix milliseconds, a speaker name and the words.
• User or workspace: Any user can create a user webhook, which pushes only their own reports, on meeting_end. Workspace admins and owners create workspace webhooks, which push every member's reports to one endpoint and offer both triggers. The caps are 20 per user and 20 per workspace.
• Signing and delivery: Every delivery carries X-Read-Signature, an HMAC SHA-256 of the raw request body made with a signing key generated per webhook. To verify, keep the body unparsed, compute the HMAC SHA-256 with the key and compare it with the header. Read's sample code base64-decodes the key first and compares hex digests in constant time. Signatures exist only on webhooks created after March 17, 2026; older ones must be deleted and re-created. request_id lets you drop duplicates. Any status above 299 triggers up to 5 retries (6 attempts in total), and after 25 consecutive failures the webhook is marked Stopped.
• Scope: A webhook fires only for reports the member could access directly when the report was created, so reports visible only through Team Report Access or Global Report Access do not send. Reports generated from file uploads never trigger one, automatically or by hand.
• Plan: Read says webhooks are available on Pro, Enterprise and Enterprise+, and its pricing page lists them among the premium integrations on Pro, at $15 per user per month billed annually. If a subscription ends, the webhooks stop.
• Why I'd pick it: One signed request carries the summary, action items, key questions, chapter summaries and full transcript, a workspace webhook gives an admin one endpoint for every member, and meeting_start lets you react before a report exists.
• Limits: meeting_start is for workspace webhooks only, and the direct-access rule means some meetings never send.

Side by side

How to set up a Circleback webhook

1. Open Automations and select New automation.
2. Add conditions if you want to limit which meetings send. With none, every meeting sends.
3. Add the webhook step, enter your HTTPS endpoint URL and tick the outcomes to include: notes, action items, transcript, AI insights.
4. Copy the signing secret from the step. Check the X-Signature header against the raw request body before you parse the JSON.
5. Use "Send request for most recent meeting" to check your endpoint, then select Save. To back-fill, run the automation by hand on past meetings.

How to choose

If you need webhooks on every plan, choose Fathom. If you want events split by stage, choose Fireflies.ai and budget for a fetch per meeting. If you want your own auth header and team or organization scope, choose tl;dv. If an admin should collect every member's reports at one endpoint, choose Read AI. Otherwise I'd go with Circleback.

Otter.ai offers workspace webhooks on its Enterprise plan, created by workspace admins with a workspace or a channel as the source. They fire on conversation.completed or conversation.shared and carry the summary, action items, insights, outline and transcript, with 2 extra attempts per conversation. A webhook cannot be edited after creation, and a meeting must be shared to the workspace or channel before it ends.

Granola has webhooks on Business and Enterprise that work like Fireflies.ai's: note.generated, note.edited and note.access_granted events carry an event ID, a note ID and a timestamp but no note content, so you fetch the note with a Granola API key. Deliveries are signed per the Standard Webhooks specification, can be filtered by folder, and retry with exponential backoff for four days.

For a signed webhook (Circleback, Fireflies.ai with a secret set, Fathom, Read AI, Granola), verify the signature against the raw body before parsing. With tl;dv, check the header you set. Dedupe on a stable ID: the meeting id for Circleback, webhook-id for Fathom, meeting_id plus reprocessed_at for Fireflies.ai and request_id for Read AI. Make connects to Circleback through the webhook step, and Pipedrive has no built-in integration, so it goes through Zapier, Make or the webhook step.

FAQ

Does the webhook payload include the full transcript?

Circleback, Fathom, tl;dv and Read AI can include it. Fireflies.ai does not, because its payload is an ID you use to fetch the transcript. Circleback adds it when you tick the transcript outcome, Fathom when include_transcript is on, and Read AI in every meeting_end request. tl;dv embeds it in MeetingReady if you opt in or sends it in TranscriptReady.

Can I limit which meetings get sent?

With Circleback, yes: automation conditions cover tags, title, participants, invitee emails, invitee email domains and number of invitees, but not meeting content. The others scope by ownership or group: Fireflies.ai by meetings you own, Fathom by the triggered_for values you pick, tl;dv by user, team or organization, and Read AI by user or workspace webhook.

How do I check that a request came from the vendor?

Compute an HMAC-SHA256 of the raw body and compare it with the signature header before you parse anything. Circleback sends X-Signature as a hex digest, Read AI sends X-Read-Signature as a hex digest made with the base64-decoded signing key, and Fireflies.ai sends X-Hub-Signature as sha256= plus the hex digest when you set a secret. Fathom signs the webhook ID, timestamp and body and sends webhook-id, webhook-timestamp and webhook-signature. tl;dv sends the custom headers you configure.

What happens if my endpoint is down?

Circleback makes up to 10 attempts on any non-2xx response. Fireflies.ai retries up to 5 times over about 3 hours. Fathom retries without publishing a schedule. tl;dv waits 10 seconds and then retries. Read AI retries up to 5 times on any status above 299 and marks the webhook Stopped after 25 consecutive failures.

Do imported meetings fire a Circleback webhook?

Not on their own. Meetings imported from Fathom, Fireflies, Granola or Read AI, or created through the import API, keep their original notes and transcript and never trigger it automatically. You can run it by hand on one only when the import brought its notes over. Uploaded audio or video files go through the normal pipeline.