Fathom integration

What it gives Plexward

Meeting summaries and action items, pulled by date or date range.
Notes written into the entity's system of record, typically the meeting sub-page for that week.
A closed loop between the recording and the written note, so the recap everyone reads is the one the meeting actually produced.

Layer

service in practice: an API key, per entity, held outside the repo and read by the skill that needs it. It has no MCP server, so claude mcp list will never see it and the probe reports unprobed. That is correct.

{ "name": "Fathom", "layer": "API", "svc": "Meetings", "account": "Acme workspace" }

Prerequisites

A Fathom account on a plan that includes API access.
An API key.
Somewhere for the notes to land: a Notion space, or the brain itself.

Setup steps

1. Store the key outside the repo.

cat > ~/.config/secrets/acme-fathom.env <<'ENV'
FATHOM_API_KEY=<key>
ENV
chmod 600 ~/.config/secrets/acme-fathom.env

2. Reference it from the brain's .env.tpl so the launcher injects it into the session environment. Never inline the value.

3. Confirm the API answers.

set -a; . ~/.config/secrets/acme-fathom.env; set +a
curl -s -H "X-Api-Key: $FATHOM_API_KEY" \
  "https://api.fathom.ai/external/v1/meetings?include_summary=true&include_action_items=true" \
  | head -c 300

4. Declare it in catalog/declarations.json with layer API, so it shows on the dashboard as a real connector that simply has no probe.

Per-entity routing

## Owned Integrations
| Service | Scope | Notes |
|---|---|---|
| Fathom (REST) | Meetings | Key in `~/.config/secrets/acme-fathom.env`. Meeting source of truth for this entity. |

## NOT This Company
- Meetings recorded for another entity, even on the same Fathom account.

Verify

Run the curl above and confirm it returns meetings you recognize. Then run the sync for a day you know had a meeting and confirm the note landed in the right place, with action items, and that re-running it does not duplicate them.

Common failures

Date filtering is client-side. The API returns a list; matching a meeting to a target date range happens in the skill. A sync that silently returns nothing is usually a timezone boundary, not an empty day.
Pagination. A cursor in the response means there are more results. A sync that only ever reads the first page will quietly miss older meetings in a range.
Title matching to a destination page is fragile. Renamed meetings stop matching. Log the unmatched ones instead of guessing a destination.
Re-runs duplicate notes unless the writer replaces a named section rather than appending.
The key is a secret in an env file, not in the brain. A key committed to a brain repo has to be rotated, not deleted.

What Plexward does with it once connected

The sync fetches the target day's meetings with summaries and action items, matches each to its destination page, and writes notes and action items into it. Everything stays in the entity's own private space: nothing is published to a shared database. From there the weekly update and the action-item board pick it up like any other note.

Fathom