Skip to main content

Overview

Webhooks V2 provides an improved webhook system with granular event subscriptions and enhanced security. You can subscribe to specific meeting lifecycle events and receive real-time notifications at your configured endpoint.
Webhooks V2 replaces the legacy webhook system. Webhooks V1 is deprecated and its Developer settings field is read-only, so all new webhooks - including team-wide Super Admin webhooks - are created here.

Events Supported

Webhooks V2 supports the following events:
You can subscribe to one or more events per webhook. Only events you subscribe to will be delivered. The Event Subscriptions list on the setup page is the source of truth for which events are currently available.

Setting Up Webhooks V2

2
Enter a valid HTTPS URL that accepts POST requests in the Webhook URL field
3
Optionally, enter a Signing Secret for payload signature verification
4
Under Event Subscriptions, select the events you want to subscribe to
5
Optionally, turn on Resend when a meeting’s notes change to receive meeting.transcribed and meeting.summarized again when a meeting’s transcript or summary changes - see Resends After a Meeting Changes
6
Save your configuration
7
Click Send Test Event to confirm your endpoint is reachable and validating payloads correctly
Webhooks are delivered for meetings you own. If you are a Super Admin on an Enterprise team, events for all meetings owned by your team are also escalated to your webhook - see Super Admin.

Webhook Payload

Each webhook notification is sent as a POST request with a JSON payload containing the following fields:
String
required
The event type that triggered the webhook (e.g., meeting.transcribed, meeting.summarized, meeting.bot_joined)
Number
required
Unix timestamp in milliseconds of when this delivery was sent. Each retry carries a new value, so use reprocessed_at rather than timestamp to order changes to a meeting.
String
required
Identifier for the meeting that the event relates to. This is the same as the transcript ID used throughout the Fireflies API.
String
Custom identifier set by you during upload. Use this to correlate webhook events with your uploads.
Number
Only present when the event is resent because the meeting’s transcript or summary changed. Unix timestamp in milliseconds of that change. It stays the same across retries of the resend, and every later change to the meeting has a later value. Omitted on the first delivery of an event.

Example Payloads

Meeting Transcribed
Meeting Summarized
Meeting Bot Joined
Meeting Summarized (resend) reprocessed_at is only sent on a resend, when the Resend when a meeting’s notes change setting is on and an already-delivered meeting’s summary changes. First deliveries never include it. See Resends After a Meeting Changes.

Resends After a Meeting Changes

By default, each event is sent once per meeting. A meeting’s transcript or summary can change after it was delivered, for example when the meeting is reprocessed, its language is changed, its notes are regenerated or a refined summary is applied. To keep your copy up to date, turn on Resend when a meeting’s notes change on the Webhooks V2 setup page. With the setting on, Fireflies sends meeting.transcribed again when an already-delivered meeting gets a new transcript, and meeting.summarized again when it gets a new summary, for the events you subscribe to. Resends carry reprocessed_at; first deliveries do not. To handle resends:
  • Store the reprocessed_at of the last version you processed for each meeting and event
  • When a payload has a reprocessed_at newer than the stored value, fetch the meeting again and replace your copy
  • Ignore a payload whose reprocessed_at equals or is older than the stored value: it is a retry or an out-of-order delivery of a change you already have

Webhook Authentication

Webhooks V2 uses HMAC-SHA256 signatures to verify that webhook payloads originate from Fireflies and have not been tampered with in transit.

How It Works

Each webhook request includes an X-Hub-Signature header containing a SHA-256 HMAC signature of the request body. The signature is computed using the signing secret you configured during setup. The signature format is:

Verifying the Signature

1
Extract the X-Hub-Signature header from the incoming request
2
Compute the HMAC-SHA256 digest of the raw request body using your signing secret
3
Prefix the hex-encoded digest with sha256=
4
Compare the computed signature with the header value using a timing-safe comparison

Verification Examples

Request Headers

Each webhook delivery includes the following headers:

Delivery Behavior

  • Webhooks are sent as POST requests to your configured URL. The URL must use HTTPS and resolve to a public host; redirects are not followed
  • Your endpoint must respond with a 2xx status code within 30 seconds of the request starting to be considered successful; the TCP connection itself must be established within 10 seconds
  • Failed deliveries are retried up to 5 times with a growing backoff - 30 seconds, 2 minutes, 10 minutes, 30 minutes and 2 hours - so a transient outage of up to ~3 hours is recovered automatically
  • Retries apply to transient failures: failures to connect (connect timeouts, DNS failures, refused or reset connections), unclassified network errors, 429 responses and 5xx responses. Other 4xx responses, TLS/certificate errors and invalid URLs are treated as permanent failures and are not retried
  • If the connection succeeds but your server does not respond within 30 seconds, the delivery is marked failed and not retried: your server most likely received the request, so a retry would duplicate it

Migrating from Webhooks V1

If you are using the legacy webhooks system, here is a summary of the key differences:

Migration Steps

2
Enter your existing webhook URL
3
If you used a signing secret, enter it in the Signing Secret field
4
Select the events you want to subscribe to (choose meeting.transcribed for equivalent V1 behavior)
5
Save and update your webhook consumer to handle the new payload format and signature header

FAQ

meeting.transcribed fires when the raw transcript is ready and available for viewing. meeting.summarized fires after the AI-generated summary (including action items, notes, and other insights) has been processed.
meeting.bot_joined fires when the Fred bot successfully joins a meeting. This is useful for triggering real-time workflows as soon as the bot is in the call.
Only if you turn on Resend when a meeting’s notes change. Fireflies then sends meeting.transcribed and meeting.summarized again when a meeting’s transcript or summary changes, with a reprocessed_at field. See Resends After a Meeting Changes. A failed delivery can also be retried; see Delivery Behavior.
Yes. You can select one or more events during setup. Only events you subscribe to will trigger webhook deliveries.
  • Webhooks are only fired for meetings you own (i.e., you are the organizer_email).
  • Ensure your endpoint accepts POST requests and responds with a 2xx status code within 30 seconds.
  • Verify that you have subscribed to the correct events.
  • If using signature verification, ensure your signing secret matches what is configured.

Team-wide webhooks are only supported for the Enterprise tier with the Super Admin role. This allows you to setup one webhook for all meetings owned by your team. Details here.

Existing V1 webhooks continue to be delivered, but V1 is deprecated and new V1 webhooks can no longer be saved. Migrate when convenient to get granular event subscriptions and the current payload format.
The optional webhook field on the uploadAudio mutation still works and still delivers the legacy V1 payload shape (meetingId, eventType) for that single upload. It is independent of your saved V2 webhook.

Additional Resources

Webhooks V1

Legacy webhook documentation

Upload Audio

Use the API to upload audio to Fireflies.ai