sales-fireflies

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fireflies.ai Platform Help

Fireflies.ai平台帮助

Step 1 — Gather context

步骤1 — 收集上下文

references/learnings.md

exists, read it first for accumulated platform knowledge.

Ask the user:

What's your goal?
- A) API integration (transcripts → CRM, warehouse, Slack, internal app)
- B) Webhook setup or signature verification (V1 or V2)
- C) Plan selection / pricing decision (Free, Pro, Business, Enterprise)
- D) Bot / auto-join behavior (Fred joining or missing meetings, auto-join toggles)
- E) AskFred AI, Real-time API, or MCP usage
- F) Troubleshooting a specific error (auth_failed, rate limit, missing webhook)
Who owns the meetings?
- A) Individual user (personal API key)
- B) Team-wide (Enterprise Super Admin required for team webhooks)
If API integration, destination?
- A) CRM (HubSpot, Salesforce) native sync
- B) Warehouse (Snowflake, BigQuery, Redshift)
- C) Slack / notifications
- D) Custom app or database

Skip-ahead rule: if the prompt already has enough context, skip to Step 2.

如果

references/learnings.md

存在，请先阅读该文档获取积累的平台知识。

向用户询问：

你的目标是什么？
- A) API集成（转录内容 → CRM、数据仓库、Slack、内部应用）
- B) Webhook设置或签名验证（V1或V2）
- C) 套餐选择 / 定价决策（Free、Pro、Business、Enterprise）
- D) 机器人 / 自动加入行为（Fred加入或错过会议、自动加入开关）
- E) AskFred AI、实时API或MCP的使用
- F) 特定错误排查（auth_failed、速率限制、Webhook缺失）
会议归属是谁？
- A) 个人用户（个人API密钥）
- B) 团队层面（团队Webhook需要Enterprise超级管理员权限）
如果是API集成，目标系统是什么？
- A) CRM（HubSpot、Salesforce）原生同步
- B) 数据仓库（Snowflake、BigQuery、Redshift）
- C) Slack / 通知
- D) 自定义应用或数据库

跳过规则：如果用户的提示已经包含足够上下文，直接进入步骤2。

Step 2 — Route or answer directly

步骤2 — 转接或直接解答

Problem domain	Route to
Comparing Fireflies vs Fathom/Avoma/Gong/Otter, picking a note-taker	Run: `/sales-note-taker {user's original question}`
Reviewing a specific call for coaching or scoring	Run: `/sales-call-review {user's original question}`
Building a coaching program from call data	Run: `/sales-coaching {user's original question}`
General CRM integration patterns (iPaaS, Zapier, webhooks) across tools	Run: `/sales-integration {user's original question}`

Otherwise, answer directly below.

问题领域	转接至
对比Fireflies与Fathom/Avoma/Gong/Otter、选择会议记录工具	执行： `/sales-note-taker {用户原始问题}`
为辅导或评分目的复盘特定通话	执行： `/sales-call-review {用户原始问题}`
基于通话数据构建辅导项目	执行： `/sales-coaching {用户原始问题}`
跨工具的通用CRM集成模式（iPaaS、Zapier、webhooks）	执行： `/sales-integration {用户原始问题}`

否则，直接在下方解答。

Step 3 — Fireflies platform reference

步骤3 — Fireflies平台参考

Read
references/platform-guide.md
for the full platform reference — modules, pricing, integrations, GraphQL data model, common workflows (CRM sync, warehouse pipeline, HMAC verification, Webhooks V2 migration).

Read
references/fireflies-api-reference.md
for verbatim GraphQL docs — every query, mutation, webhook schema, and SDK example. Grep for the specific operation you need (e.g.,

transcripts(

uploadAudio

meeting.summarized

) rather than loading the whole file.

Answer the user's question using only the relevant section. Don't dump the full reference.

**阅读

references/platform-guide.md

**获取完整平台参考——模块、定价、集成、GraphQL数据模型、常见工作流（CRM同步、数据仓库管道、HMAC验证、Webhooks V2迁移）。

**阅读

references/fireflies-api-reference.md

**获取准确的GraphQL文档——所有查询、突变、Webhook schema和SDK示例。针对你需要的特定操作（如

transcripts(

或

uploadAudio

或

meeting.summarized

）进行检索，无需加载整个文件。

仅使用相关部分回答用户问题，不要输出完整参考内容。

Step 4 — Actionable guidance

步骤4 — 可落地指导

You no longer need the platform guide — focus on the user's specific situation.

API design rule of thumb: GraphQL means you can request exactly the fields you need. Don't fetch
```
transcript.sentences
```
+
```
audio_url
```
+
```
summary
```
for 100 meetings in one query — GraphQL complexity limits bite. Fetch metadata in one query, then fetch transcripts per-meeting in response to webhooks.
Webhook choice: For new integrations, use Webhooks V2 (
```
meeting.transcribed
```
+
```
meeting.summarized
```
events, granular subscription). V1 still works but only fires one event and uses a different payload shape.
Rate-limit sizing: Free/Pro = 50 req/day — barely enough for backfills. Business/Enterprise = 60 req/min — the only realistic tier for a production pipeline. Anything beyond that needs queue-and-retry.
Team-wide webhooks require Enterprise + Super Admin role. Without those, each user must configure their own webhook — doesn't scale.

If you discover a gotcha, workaround, or tip not covered in

references/learnings.md

, append it there with today's date.

你无需再依赖平台指南——聚焦用户的具体场景。

API设计经验法则：GraphQL允许你请求恰好需要的字段。不要在一个查询中为100个会议获取
```
transcript.sentences
```
+
```
audio_url
```
+
```
summary
```
——GraphQL复杂度限制会触发问题。先在一个查询中获取元数据，然后通过Webhook响应按会议获取转录内容。
Webhook选择：对于新集成，使用Webhooks V2（
```
meeting.transcribed
```
+
```
meeting.summarized
```
事件、精细化订阅）。V1仍可使用，但仅触发一个事件且负载格式不同。
速率限制适配：Free/Pro套餐=每日50次请求——仅够用于回填。Business/Enterprise套餐=每分钟60次请求——这是生产管道唯一可行的套餐。超出此限制需要使用队列重试机制。
团队级Webhook需要Enterprise套餐+超级管理员角色。没有这些权限的话，每个用户必须自行配置Webhook——无法规模化。

如果你发现

references/learnings.md

未涵盖的陷阱、解决方案或技巧，请添加到该文档中并标注今日日期。

Gotchas

常见陷阱

Best-effort from research — review plan-gated features and integration details before quoting to a customer.

Webhooks fire only for meeting owners (
```
organizer_email
```
). If a non-owner attendee recorded the meeting via Fred, no webhook fires for them. Team-wide webhooks exist but require Enterprise + Super Admin.

V1 and V2 webhooks coexist. Both use

X-Hub-Signature

with

sha256=<hex>

format, but V1 has one event (

Transcription completed

) with

meetingId/eventType

payload, while V2 supports

meeting.transcribed

and

meeting.summarized

with

meeting_id/event/timestamp

. Don't mix consumers.

meeting.transcribed
≠
meeting.summarized
. Transcript is ready before the AI summary is. Subscribe to both if you need action items / notes — or accept a 1-3 minute delay and fetch summary by polling after transcript.
Free and Pro tiers are capped at 50 API requests per day. A single backfill of 500 historical meetings will hit this hard. Upgrade to Business or Enterprise for a 60 req/min ceiling.
Add to Live is 3 req per 20 min, Share Meeting is 10 req/hour (up to 50 emails per request) — these are separate from the standard GraphQL limits.
Upload limits: 200MB audio for all tiers; 100MB video on Free, 1.5GB video on paid tiers.
Bot auto-join complaints are common — granting calendar access makes Fred auto-join every scheduled call. Users frequently ask how to disable this; point them to the Fireflies dashboard's Auto-join settings (calendar-level and meeting-level).
API key is user-scoped — it only accesses meetings that user recorded or that were shared to them. For a shared team pipeline, use Super Admin.
10-second webhook response SLA on V2. Non-2xx or a timeout marks delivery failed. Do not do heavy processing inside the webhook handler — enqueue and ack immediately.

基于研究的最佳实践——向客户说明前，请确认套餐专属功能和集成细节。

Webhook仅对会议所有者触发（
```
organizer_email
```
）。如果非所有者参会者通过Fred录制会议，不会为他们触发Webhook。团队级Webhook存在，但需要Enterprise套餐+超级管理员权限。
V1和V2 Webhook可共存。两者均使用
```
X-Hub-Signature
```
的
```
sha256=<hex>
```
格式，但V1仅有一种事件（
```
Transcription completed
```
），负载包含
```
meetingId/eventType
```
；而V2支持
```
meeting.transcribed
```
和
```
meeting.summarized
```
事件，负载包含
```
meeting_id/event/timestamp
```
。不要混合使用消费者。
meeting.transcribed
≠
meeting.summarized
。转录内容在AI摘要生成前就已就绪。如果你需要行动项/笔记，请同时订阅两个事件——或接受1-3分钟延迟，在转录完成后通过轮询获取摘要。
Free和Pro套餐每日API请求上限为50次。单次回填500条历史会议记录会直接触发限制。升级到Business或Enterprise套餐可获得每分钟60次请求的上限。
实时添加功能每20分钟限制3次请求，分享会议功能每小时限制10次请求（每次请求最多50封邮件）——这些限制独立于标准GraphQL限制。
上传限制：所有套餐支持200MB音频；Free套餐支持100MB视频，付费套餐支持1.5GB视频。
机器人自动加入投诉频发——授予日历访问权限后，Fred会默认自动加入所有预定会议。用户经常询问如何禁用此功能；请引导他们前往Fireflies控制台的自动加入设置（日历级别和会议级别）。
API密钥是用户专属的——仅能访问该用户录制或共享给自己的会议。对于共享团队管道，请使用超级管理员密钥。
V2 Webhook有10秒响应SLA。非2xx响应或超时会标记为投递失败。不要在Webhook处理程序中进行重型处理——应立即入队并确认接收。

Related skills

Examples

示例

Example 1: Transcripts not arriving in Snowflake after webhook event

示例1：Webhook触发后转录内容未同步到Snowflake

User says: "My Fireflies webhook fires, but the transcript body is empty when I fetch it. What's wrong?" Skill does:

Recognizes the classic "transcribed ≠ summarized" race — V1 webhook fires the moment ASR completes, often before AskFred summary is generated
Recommends migrating to Webhooks V2 and subscribing to
```
meeting.summarized
```
instead of (or in addition to)
```
meeting.transcribed
```
— then fetch transcript after summary event
Alternative: keep V1 and re-fetch from
```
transcript(id: ...)
```
query 60-180s after the webhook, with exponential backoff
Notes that V2 also gives timing-safe signature comparison headers (
```
sha256=<hex>
```
on
```
X-Hub-Signature
```
) — points to the Node/Python examples in
```
references/fireflies-api-reference.md
```
Result: Root-caused the empty-transcript race, with two concrete fixes.

用户问题："我的Fireflies Webhook触发了，但我获取到的转录内容是空的。这是怎么回事？" 技能处理流程：

识别典型的“转录完成≠摘要生成”竞争问题——V1 Webhook在ASR完成时立即触发，通常早于AskFred摘要生成
建议迁移到Webhooks V2，订阅
```
meeting.summarized
```
事件（替代或补充
```
meeting.transcribed
```
）——然后在摘要事件触发后获取转录内容
备选方案：保留V1，在Webhook触发后60-180秒重新调用
```
transcript(id: ...)
```
查询，并使用指数退避策略
说明V2还提供时序安全的签名对比头（
```
X-Hub-Signature
```
中的
```
sha256=<hex>
```
）——指向
```
references/fireflies-api-reference.md
```
中的Node/Python示例结果：定位到空转录内容的竞争问题，并提供两个具体解决方案。

Example 2: Picking a tier for a 30-person sales team with warehouse pipeline

示例2：为30人销售团队选择适配数据仓库管道的套餐

User says: "We have 30 reps doing ~50 calls/week and want every transcript in BigQuery within 5 min. Which Fireflies tier?" Skill does:

Rules out Free ($0) and Pro ($10/seat) — both capped at 50 API requests per day, would break on day one of backfill
Recommends Business ($19/seat) for the 60 req/min ceiling, unlimited storage, and video recording
Flags that team-wide webhooks require Enterprise + Super Admin ($39/seat) — without it, each rep has to configure their own webhook
Suggests Enterprise if compliance (HIPAA, custom retention) or SSO/SCIM matters, otherwise Business with a shared team API key from the super-admin
Architecture sketch: Webhooks V2
```
meeting.summarized
```
→ Cloud Run →
```
transcripts(id: ...)
```
query → raw JSON to GCS + normalized rows to BigQuery via scheduled load Result: Tier recommendation grounded in both pricing and the team-webhook gotcha.

用户问题："我们有30名销售代表，每周约进行50次通话，希望所有转录内容在5分钟内同步到BigQuery。应该选择Fireflies的哪个套餐？" 技能处理流程：

排除Free（0美元）和Pro（10美元/席位）套餐——两者均限制每日50次API请求，回填第一天就会触发限制
推荐Business（19美元/席位）套餐，支持每分钟60次请求上限、无限存储和视频录制
指出团队级Webhook需要Enterprise套餐+超级管理员权限（39美元/席位）——没有此权限的话，每个销售代表必须自行配置Webhook
如果合规性（HIPAA、自定义保留期）或SSO/SCIM很重要，建议选择Enterprise套餐；否则选择Business套餐并使用超级管理员的共享团队API密钥
架构草图：Webhooks V2
```
meeting.summarized
```
→ Cloud Run →
```
transcripts(id: ...)
```
查询 → 原始JSON存储到GCS + 规范化数据通过定时加载同步到BigQuery 结果：基于定价和团队Webhook陷阱给出套餐推荐。

Example 3: Fred bot joining meetings nobody invited him to

示例3：Fred机器人未经邀请加入会议

User says: "Fireflies keeps joining meetings I didn't ask it to. How do I stop this?" Skill does:

Explains the behavior — granting calendar access causes Fred to auto-join every scheduled meeting by default
Points to the Auto-join settings in the Fireflies dashboard: globally toggle off, or per-meeting toggle via calendar event title (
```
#noff
```
,
```
#onff
```
) or direct disable
For Teams/Zoom admins wanting to block Fred at org level: remove calendar OAuth scope, block the Fred user in Teams admin center, or use SSO to deprovision
Notes this is the #1 user complaint on G2/Reddit — not a bug, a default setting Result: Tactical fix plus org-level block path.

用户问题："Fireflies总是加入我没邀请它的会议。怎么阻止？" 技能处理流程：

解释该行为——授予日历访问权限后，Fred默认会自动加入所有预定会议
引导用户前往Fireflies控制台的自动加入设置：全局关闭，或通过日历事件标题（
```
#noff
```
、
```
#onff
```
）按会议关闭，或直接禁用
对于想要在组织层面阻止Fred的Teams/Zoom管理员：移除日历OAuth权限、在Teams管理中心阻止Fred用户，或使用SSO取消授权
说明这是G2/Reddit上排名第一的用户投诉——这不是bug，而是默认设置结果：提供战术修复方案和组织层面的阻止路径。

Troubleshooting

故障排查

Webhook doesn't fire at all

Webhook完全未触发

Symptom: A meeting completes, transcript is viewable in the dashboard, but no webhook POST is received. Cause: The webhook is configured under a user account that isn't the meeting owner (

organizer_email

). Fireflies only fires for the owner. Solution: Either (a) make the user with the configured webhook the organizer of the calendar event, or (b) upgrade to Enterprise and set up a Super Admin team-wide webhook that catches all org meetings regardless of owner. Verify your endpoint accepts POST with

Content-Type: application/json

and responds 2xx within 10 seconds.

症状：会议结束，转录内容可在控制台查看，但未收到Webhook POST请求。原因：Webhook配置在非会议所有者（

organizer_email

）的用户账户下。Fireflies仅会为所有者触发Webhook。 解决方案：要么(a) 将配置Webhook的用户设为日历事件的组织者，要么(b) 升级到Enterprise套餐并设置超级管理员团队级Webhook，可捕获组织内所有会议（无论所有者是谁）。验证你的端点接受

Content-Type: application/json

的POST请求，并在10秒内返回2xx响应。

"auth_failed" or 401 on GraphQL calls

GraphQL调用返回"auth_failed"或401

Symptom:

{"errors": [{"message": "auth_failed"}]}

on every request. Cause: Authorization header missing, malformed, or using a rotated/expired key. Solution: Confirm the header is exactly

Authorization: Bearer your_api_key

(note: word

Bearer

+ space + key). Regenerate the key in dashboard → Integrations → Fireflies API if you suspect rotation. API keys are user-scoped — if you're trying to access a teammate's meetings, you need them shared to your account or a Super Admin key on Enterprise.

症状：每次请求均返回

{"errors": [{"message": "auth_failed"}]}

。原因：缺少Authorization头、格式错误，或使用了已轮换/过期的密钥。 解决方案：确认头格式为

Authorization: Bearer your_api_key

（注意：单词

Bearer

+ 空格 + 密钥）。如果怀疑密钥已轮换，在控制台→集成→Fireflies API中重新生成密钥。API密钥是用户专属的——如果你尝试访问同事的会议，需要他们将会议共享给你，或使用Enterprise套餐的超级管理员密钥。

Hitting 50 req/day on Free/Pro during a backfill

Free/Pro套餐回填时触发每日50次请求限制

Symptom: After ~50 requests, every call returns a rate-limit error until the next day. Cause: Free/Pro plans are intentionally capped at 50 requests per day (not per minute). This is not the same as Business's 60 req/min ceiling. Solution: Either upgrade to Business ($19/seat/mo annual) for 60 req/min, or spread the backfill across multiple days using the

date_from

date_to

filter on

transcripts(...)

. For production pipelines, Business is effectively the minimum viable tier.

症状：约50次请求后，所有调用均返回速率限制错误，直到次日重置。原因：Free/Pro套餐特意限制为每日50次请求（不是每分钟）。这与Business套餐的每分钟60次请求上限不同。 解决方案：要么升级到Business套餐（19美元/席位/月，按年付费）获得每分钟60次请求上限，要么使用

transcripts(...)

的

date_from

date_to

过滤器将回填分散到多天。对于生产管道，Business套餐实际上是最低可行套餐。