feat(fathom): add Fathom AI Notetaker integration

[waleedlatif1]

Summary

• Add 5 tools: list meetings, get summary, get transcript, list team members, list teams
• Add block with operation dropdown, conditional subBlocks, pagination, and all API filters
• Add 2 webhook triggers (new meeting, generic) with automatic lifecycle management
• Wire webhook create/delete in provider-subscriptions.ts
• Add docs page and icon

Type of Change

• New feature

Testing

Tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 12, 2026 5:53pm

[cursor]

PR Summary

Medium Risk
Adds a new third-party integration that makes authenticated requests to Fathom APIs and creates/deletes external webhook subscriptions; failures or misconfig could impact webhook lifecycle and data returned to workflows.

Overview
Adds a new Fathom integration across the app: a fathom block with an operation selector (list meetings, fetch summary/transcript, list members/teams) backed by 5 new Fathom tool implementations and shared response types.

Introduces two Fathom webhook triggers (fathom_new_meeting, fathom_webhook) and wires automatic external webhook subscription create/delete into provider-subscriptions.ts (including input validation and user-friendly errors).

Updates docs to include a new fathom tool page, adds FathomIcon, and registers the new block/tools/triggers in the relevant registries and docs icon mapping.

^{Written by Cursor Bugbot for commit 2d394ca. Configure here.}

[greptile-apps]

Greptile Summary

This PR adds a full Fathom AI Notetaker integration to Sim, including 5 tools (list meetings, get summary, get transcript, list team members, list teams), 2 webhook triggers (new meeting content, generic), automatic webhook lifecycle management, a block with operation dropdown and conditional subBlocks, an icon, and a docs page. The implementation follows the established patterns for provider integrations in the codebase (e.g., Grain, Circleback) and incorporates several fixes from prior review rounds.

Key observations:

• The toBool helper in createFathomWebhookSubscription only guards against undefined but not null; if providerConfig fields are ever serialised as null (e.g., from a database round-trip), include_summary would silently default to false instead of the intended true
• Neither the fathom_new_meeting nor fathom_webhook trigger verifies the authenticity of incoming POST payloads — if Fathom offers a webhook signing secret, it should be used; even if not currently available, a comment tracking this gap would be valuable
• The include-flag tool parameters (includeSummary, etc.) are typed as string and compared with === 'true', but callers (including LLMs) may pass the boolean true, which would silently skip the filter with no error

Confidence Score: 3/5

• Mostly safe to merge with minor logic and security concerns that should be addressed before production use
• The core tool and block implementation is solid and follows established codebase patterns. Previous review rounds addressed the most critical bugs (response.ok checks, null recording_id, crm_matches mapping, include flag defaults). The remaining issues are an edge-case null-handling bug in toBool that could silently suppress the include_summary default, a missing webhook signature check that creates a spoofing surface, and a string/boolean type mismatch in include-flag params that can silently no-op LLM-provided values.
• apps/sim/lib/webhooks/provider-subscriptions.ts (toBool null handling), apps/sim/triggers/fathom/webhook.ts and new_meeting.ts (missing signature verification)

Important Files Changed

Filename	Overview
apps/sim/lib/webhooks/provider-subscriptions.ts	Adds createFathomWebhookSubscription and deleteFathomWebhook; the toBool helper does not guard against null, which can coerce the include_summary default from true to false in edge cases.
apps/sim/triggers/fathom/webhook.ts	Defines the generic Fathom webhook trigger with correct subBlock structure; lacks incoming payload signature verification, which could allow spoofed requests to trigger workflows.
apps/sim/triggers/fathom/new_meeting.ts	Defines the "new meeting content" Fathom trigger; mirrors webhook.ts structure correctly but shares the same missing signature-verification concern.
apps/sim/tools/fathom/list_meetings.ts	Implements list-meetings tool with correct response.ok guard, null-safe transforms, and crm_matches mapping; include-flag params are string typed but callers passing boolean true would silently skip the filter.
apps/sim/blocks/blocks/fathom.ts	Block config with operation dropdown, conditional subBlocks, and trigger integration; well structured with correct tool routing.
apps/sim/triggers/fathom/utils.ts	Shared output schema and setup instruction helpers; crm_matches and all webhook payload fields are included.

Sequence Diagram

sequenceDiagram
    participant User as User (UI)
    participant Sim as Sim Backend
    participant FathomAPI as Fathom API
    participant Webhook as Sim Webhook Endpoint

    Note over User,FathomAPI: Webhook Registration Flow
    User->>Sim: Save trigger config (apiKey, triggeredFor, include flags)
    Sim->>Sim: createFathomWebhookSubscription()
    Sim->>FathomAPI: POST /external/v1/webhooks<br/>{destination_url, triggered_for, include_*}
    FathomAPI-->>Sim: {id: "fathom-webhook-id"}
    Sim->>Sim: Store externalId in webhookData

    Note over FathomAPI,Webhook: Incoming Event Flow
    FathomAPI->>Webhook: POST /api/webhooks/trigger/{path}<br/>Meeting payload
    Webhook->>Sim: Process trigger (no signature check)
    Sim->>User: Execute workflow with meeting data

    Note over User,FathomAPI: Tool Usage Flow
    User->>Sim: List Meetings / Get Summary / Get Transcript
    Sim->>FathomAPI: GET /external/v1/meetings<br/>or /recordings/{id}/summary<br/>or /recordings/{id}/transcript
    FathomAPI-->>Sim: Meeting data / Summary / Transcript
    Sim-->>User: Transformed response

    Note over Sim,FathomAPI: Webhook Deletion Flow
    User->>Sim: Remove trigger
    Sim->>Sim: deleteFathomWebhook()<br/>validateAlphanumericId(externalId)
    Sim->>FathomAPI: DELETE /external/v1/webhooks/{externalId}
    FathomAPI-->>Sim: 204 No Content

Loading

Comments Outside Diff (3)

1. apps/sim/lib/webhooks/provider-subscriptions.ts, line 1401-1413 (link)

   toBool silently coerces null to false instead of falling back

   The toBool helper only guards === undefined, but database-stored JSON can deserialise missing fields as null. When that happens:

   toBool(null, true)  // returns false — not the intended fallback!

   This means include_summary would be sent as false even though the intended default is true, potentially surprising users who never touched the toggle. The guard should cover both null and undefined:

2. apps/sim/triggers/fathom/webhook.ts, line 122-128 (link)

   No incoming webhook signature verification

   Neither fathom_webhook nor fathom_new_meeting verifies that an incoming POST actually originates from Fathom. Any party who discovers the webhook URL (e.g., from a log or a shared URL) can send a crafted payload and trigger a workflow with arbitrary data.

   If the Fathom API offers a signing secret or HMAC header when creating a webhook, the destination_url call in createFathomWebhookSubscription should request one and this trigger config should validate it (similar to how other providers in the codebase validate X-Hub-Signature / X-Webhook-Signature).

   Even if Fathom does not yet expose a signing mechanism, it is worth adding a comment here to track this gap so future maintainers do not overlook it.

   The same concern applies to apps/sim/triggers/fathom/new_meeting.ts lines 122-128.

3. apps/sim/tools/fathom/list_meetings.ts, line 17-40 (link)

   Include-flag params typed as string but downstream comparisons expect booleans

   includeSummary, includeTranscript, includeActionItems, and includeCrmMatches are declared with type: 'string' in the tool params, and the URL builder correctly compares them with === 'true'. However, the FathomListMeetingsParams interface in types.ts types these as string | undefined, while the block subBlocks return the string ids 'true' / 'false' from the dropdown.

   This means an LLM or external caller that passes boolean true instead of the string 'true' would silently get no filter applied (the === 'true' check would fail). Documenting the expected string format explicitly in the description field (e.g. "Pass 'true' or 'false' as a string") would prevent silent mismatch.

_{Last reviewed commit: 2d394ca}

[waleedlatif1]

@greptile review

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile review

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

2 issues from previous reviews remain unresolved.

Comment @cursor review or bugbot run to trigger another review on this PR