---
name: fathom-oauth-app
description: Registers a Fathom (fathom.video AI meeting notetaker) OAuth2 app to obtain a client ID and client secret — covering the self-serve marketplace-application form, the one-production-redirect-URI rule that forces one app per data center, the single `public_api` scope, one-time-use rotating refresh tokens, and the per-customer API-key route that is the alternative. Use when asked to get Fathom OAuth credentials, register a Fathom app, set up a Fathom developer account, wire Fathom meeting/transcript/webhook access for many customers, or debug a Fathom connection that authorizes but returns only one person's meetings, returns no summaries, or breaks on the second refresh. Not for Fathom Analytics (usefathom.com). For any other vendor's developer portal, use that vendor's skill instead.
---

# Fathom OAuth2 App Registration

**Which Fathom this is:** the **AI meeting notetaker** — `fathom.video` / `fathom.ai`, developer docs at
`developers.fathom.ai`, API at `https://api.fathom.ai/external/v1`, objects called *meetings*, *recordings*,
*transcripts*, *teams*. It is **not Fathom Analytics (`usefathom.com`)**, the privacy-first website analytics product
whose API talks about *sites*, *pageviews* and site-scoped API tokens. If the page in front of you says "sites", close
it — you are on the wrong Fathom.

Get a working Fathom OAuth2 client — a Fathom account, a registered marketplace application, redirect URIs, the
`public_api` scope, and a client ID and secret — for a platform that connects many customers' Fathom accounts.

Four things here cost more than they look.

1. **One production redirect URI per app.** Fathom's FAQ is explicit: multiple *development* redirect URIs are
   supported, and "for multiple production URIs, use separate OAuth apps." A platform with four regional callbacks
   therefore needs **four apps and four credential pairs**, not one app with four URIs (§4).
2. **OAuth tokens cannot ask `/meetings` for content.** `include_summary` and `include_transcript` are documented as
   "Unavailable for OAuth connected apps." Summaries and transcripts must be fetched one recording at a time from the
   `/recordings` endpoints — which are the *heavy* rate-limit class, 30 calls per 60 seconds and reducible to 5 (§8).
3. **There is exactly one scope, `public_api`.** There is no read/write split and no per-object scope. What a
   credential can see is decided entirely by the Fathom user's own view permissions — which is also the single most
   common support ticket in this category (§6).
4. **Refresh tokens are one-time-use and rotate.** Two workers refreshing the same connection concurrently means one
   succeeds and the other gets **HTTP 400** (§7).

## Inputs to collect before you start

Ask in one batch. Never invent.

| Input | Notes |
| --- | --- |
| **App name**, description, logo | Shown to the customer at install and on any listing |
| **Which Fathom account registers the app** | Registration is behind a normal Fathom login (§2) |
| **Route: OAuth app, or per-customer API keys** | Decides everything downstream (§1) |
| **Every production callback URL** | One per app — count them, that is your app count (§4) |
| **Development callback URLs** | Multiple are allowed on one app (§4) |
| **Whether customers need org-wide coverage** | Drives the admin view-access conversation (§6) |
| **Whether you need webhooks** | Secret and webhook ID are returned **once**, at creation (§7, §8) |
| **Whether you need media downloads** | Separate rate class, signed URLs expire ~24h (§8) |
| **Support/contact address for launch** | Fathom routes partner questions through `help@fathom.video` |

## Quick Start

1. Confirm the route — OAuth app for a multi-tenant connector, API keys for one customer's own tooling (§1).
2. Count production callbacks; that is how many apps you will register (§4).
3. Sign in to Fathom with the account that will own the app (§2).
4. Register at `https://fathom.video/marketplace_applications/new` — a ~2-minute self-serve form (§3).
5. Enter redirect URIs; HTTPS is required (§4).
6. Use the only scope there is: `public_api` (§5).
7. Read §6 before promising any customer "all our meetings" — that is not what a credential gets by default.
8. Capture client ID and secret; store rotated refresh tokens and take a lock around refresh (§7).
9. Verify from a **second, unrelated** Fathom account, then hand the credentials over (§9, §10).

## Platform state (verified 2026-09-20 — re-verify before trusting)

- **OAuth registration is self-serve, not partner-gated.** Fathom's OAuth guide points at
  `https://fathom.video/marketplace_applications/new` with the caption "Configure your redirects and receive your
  OAuth credentials. (2 mins)". Nothing in the documented flow makes credentials wait on a partnership call.
- **The "review" in Fathom's OAuth page is about promotion, not permission.** The page says OAuth apps "are eligible
  for promotion by Fathom and can unlock visibility in our App Marketplace… They are subject to review to ensure the
  best experience for all users," and then describes the mechanism: a **quarterly** review of app usage, and at
  **20+ users** Fathom reaches out about their integrations listing, Crossbeam and co-marketing. No documented
  pre-launch approval gate blocks installs. If the registration form tells you otherwise, stop and report that.
- **API access is on every plan.** "API access—keys and webhooks—are included on all plans." There is no API tier to
  buy, and recordings/transcripts/summaries are not separately licensed add-ons.
- **One scope exists: `public_api`.** "Currently, the only available scope is: `public_api` — Access to the Fathom API."
- **Documented token endpoint:** `https://api.fathom.ai/external/v1/oauth2/token`, `application/x-www-form-urlencoded`,
  grant types `authorization_code` and `refresh_token`, with `client_id` and `client_secret` **in the body** — no HTTP
  Basic variant is documented. Fathom's own partner example (Pylon) posts to the same URL the same way.
- **The literal authorize URL is not printed in the docs** — the SDKs build it from client ID, redirect URI, scope and
  state. Observed on 2026-09-20: an unauthenticated `GET /external/v1/oauth2/authorize` returns **302 to that host's
  sign-in page** on both `api.fathom.ai` and `fathom.video`, while an unknown path under the same prefix returns 404.
  Treat the exact host as **confirmed by behaviour, not by documentation**, and take the value the registration form
  or SDK gives you over any value you inherited.
- **Refresh tokens are single-use and rotate.** Each refresh returns a new access token *and* a new refresh token and
  invalidates the old one; an unused refresh token "stays valid until the user revokes access." Concurrent refresh of
  one connection returns **HTTP 400** to the loser — "wrap refreshes in a lock if you run them concurrently."
- **Redirect URIs must be HTTPS**, multiple **development** URIs are supported, and **multiple production URIs are
  not** — use separate apps.
- **API shape:** base `https://api.fathom.ai/external/v1`; cursor pagination via `next_cursor` → `cursor`; **default
  page size 10 and no parameter to raise it**; no bulk endpoint; no `GET /meetings/{id}` — you list with filters, and
  the numeric ID in a Fathom call URL is **not** the `recording_id` the API uses.
- **Rate limits:** 60 requests per 60 seconds globally, **per account** (per API key or OAuth token); **heavy
  requests** — the `/recordings` summary and transcript endpoints, plus `/meetings` with `include_summary` or
  `include_transcript` — 30 per 60 seconds, "during periods of elevated activity this limit may be adjusted down to 5
  every 60 seconds"; recording downloads 30 per 60 seconds; the OAuth token endpoint 60 per 60 seconds **per OAuth
  app**. Responses carry `RateLimit-Limit`, `RateLimit-Remaining`, `RateLimit-Reset`, and `Retry-After` on 429.
- **Recently added** (Fathom changelog): API + SDKs + webhooks October 2025; MCP April 2026; `meeting_url`,
  `meeting_type`, `include_highlights`, `shared_with`, and webhook `id` in June 2026; the **download** endpoint and
  the **users-and-permissions** endpoint in July 2026. Anything written before mid-2026 will not know about the last
  two.
- **No real-time transcripts.** "Transcripts are available only after post-call processing completes."

If the portal or the docs do not look like this, stop and report what you actually see rather than clicking on.

## 1. Decide: OAuth app, or per-customer API keys

Fathom supports two credentials, and its own FAQ draws the line: use an **API key** "if you only need access to your
own (or your team's) meetings—for internal tools or personal automation"; use **OAuth** "if you're building an app that
other Fathom users will install so they can connect their own accounts." A platform connecting other organizations'
accounts is the OAuth case.

| | OAuth app | Per-customer API key |
| --- | --- | --- |
| Who creates it | You, once per callback host | Each customer, in their own settings |
| How it is sent | `Authorization: Bearer <token>` | `X-Api-Key: <key>` header |
| Customer effort | Click Allow | Generate a key and paste it to you |
| `include_summary` / `include_transcript` on `/meetings` | **Not available** | Available (heavy rate class) |
| Expiry | Short-lived access token + rotating refresh token | No documented expiry; dies when the user is deactivated |
| Revocation | User revokes access | Only by deactivating/removing that user — "Admins can't directly revoke another user's API key" |

A key detail for the API-key route: keys keep working if the user leaves a team or downgrades — only *what they can
see* changes. And when a user is deactivated, their key "stops working and will return **4xx**."

**Registering a new OAuth app mints a new client ID, and every existing customer authorization is bound to the old
one.** Reuse the existing app for changing a redirect, rotating a compromised secret, or diagnosing a failure.
Register a new one only for a new callback host (§4), a replacement for a compromised app, or a deliberately separate
product. Say which path you are taking before you touch anything.

## 2. Account: sign in or sign up

Sign in at `https://fathom.video/`. Observed 2026-09-20: both
`https://fathom.video/marketplace_applications/new` and the settings page at `https://fathom.video/customize` redirect
an unauthenticated request to `https://fathom.video/users/sign_in` — so a Fathom login is a prerequisite for both the
OAuth form and the API-key screen. API access is included on all plans, so a free account is enough to *register*;
what a test account can *see* is a separate question (§6).

Hand control back to a human for anything only they can do: account signup, email verification, accepting terms, or
any SSO/2FA step. Do not retry a blocked step in a loop.

**If this session has no browser automation**, do not pretend to click. Hand the user an ordered click path and the
literal values to paste — the redirect URIs from §4 and the scope from §5 — and continue when they come back with the
client ID.

## 3. Register the app

`https://fathom.video/marketplace_applications/new`, described by Fathom as "Configure your redirects and receive your
OAuth credentials. (2 mins)". The form is behind the login, so **do not narrate fields you cannot see** — read what is
on screen and report it. Expect, at minimum, an app name, redirect configuration, and the issued client ID and secret.

Launch-side expectations Fathom documents, none of which block credentials:

- Before sharing the app, review Fathom's About Us page for boilerplate language, logos and brand guidelines.
- `help@fathom.video` is the documented channel for launch support, listing copy, and API/product feedback.
- Quarterly, Fathom reviews OAuth app usage; at **20+ users** they reach out about the integrations listing,
  a Crossbeam connection and co-marketing.

## 4. Redirect URIs

**This is the section that changes your architecture.** Fathom's FAQ:

> Can a single OAuth app register multiple redirect URIs? **Only multiple development redirect URIs are supported. For
> multiple production URIs, use separate OAuth apps.**

and

> Is HTTPS required for redirect URIs? **Yes.**

So a platform that serves several data centers registers **one app per production callback** and stores a separate
client ID and secret per region. For Unified.to those callbacks are one per data center — confirm the live list with
the platform owner rather than assuming:

```
https://api.unified.to/oauth/code          # us (default)
https://api-eu.unified.to/oauth/code       # eu
https://api-au.unified.to/oauth/code       # au
https://api-dev.unified.to/oauth/code      # dev
```

Practical consequences to decide *before* registering:

- **Four apps means four consent screens and four listings.** Agree the naming with the owner ("Acme (EU)" or one name
  reused), because customers see it.
- **The dev callback may be able to ride along** as a development redirect URI on an existing app rather than needing
  its own app. Confirm against the form; the FAQ allows multiple *development* URIs but does not define which of the
  form's fields is "development."
- **A credential pair is bound to its region.** The commonest self-inflicted failure on a multi-app vendor is a
  token exchange sending region A's secret to an authorization issued for region B's client ID.

## 5. Scopes

One scope exists, and the SDK examples pass it literally:

```
public_api
```

Fathom: "Currently, the only available scope is: `public_api` — Access to the Fathom API."

What that means in practice:

- **No least-privilege lever exists at the app level.** You cannot ask for read-only, and you cannot ask for meetings
  without also being able to reach teams and team members. If a customer's security review wants narrowing, the only
  real control is the Fathom user's own view access and sharing settings (§6) — say so plainly rather than promising a
  scope you cannot request.
- **Send `scope=public_api` on the authorize request** and keep sending it; there is nothing to add later, so there is
  no incremental-consent step to design around.

## 6. What a credential can actually see — the classic failure

A valid Fathom credential that returns "only one person's meetings" is almost never broken. It is working exactly as
documented.

**The documented model, for API keys:**

- "API keys are scoped to the user who creates them. Your key can only access meetings you've recorded or that have
  been shared with you or your Team." And: "Whatever a user can view in Fathom, their API key can access."
- "**API keys are per user, not per org, and there are no org-level keys.** For org-wide access, grant one or more
  **Admins view access to all shared calls**; that Admin's key can then read everything shared across teams."
- "**API keys *never* grant access to other users' private meetings**" — admin or not. "Private calls stay host-only."

**The permission dimensions**, which Fathom exposes on its users endpoint (added July 2026, `GET /users`,
**admin only** — it returns 403 unless the caller's `settings_access` is `account_admin`):

| Dimension | Values |
| --- | --- |
| `settings_access.level` | `none`, `team_admin`, `account_admin` |
| `view_access.level` | `own_meetings`, `team`, `multiple_teams`, `all_teams` |

The two are independent — Fathom's help centre spells out that "someone can be a Team Admin and still not see team
calls if View Access is restricted." **`view_access` is the field that predicts what the customer's connection will
return.** When a customer reports missing meetings, reading that value (from an admin credential) ends the argument in
one call.

**For OAuth tokens:** Fathom describes OAuth as other users installing your app "so they can connect their own
accounts," and states that rate limits apply "per account (per API key or OAuth token)." It does **not** publish a
separate visibility rule for OAuth tokens, and there is **no documented admin-consent or org-wide install**. Plan for
a token seeing what the authorizing user sees, confirm it empirically on a multi-user test account (§9), and do not
tell a customer an OAuth install covers their whole organization until you have watched it do so.

**What to tell a customer who wants org-wide coverage:** have an Account Admin be the person who connects, and have
that admin's **view access set to all teams' calls**. Their private, unshared calls still will not appear — nothing
you configure changes that.

**Team-plan caveats** worth knowing before a small customer files a bug: the webhook trigger scopes
`my_shared_with_team_recordings` and `shared_team_recordings` are documented as **Team Plans only**, and
`my_recordings` on a Team Plan "excludes recordings you've shared with any teams."

## 7. Capture the credentials

From the registration form, capture and label:

- **Client ID** and **client secret** — one pair per app, i.e. one per production callback (§4)
- **Token endpoint** — `https://api.fathom.ai/external/v1/oauth2/token`
- **Authorize endpoint** — as given by the form/SDK (see the Platform state note; do not paste an inherited value
  without checking it)
- **Scope** — `public_api`
- **API base URL** — `https://api.fathom.ai/external/v1`

Fathom does not publish a secret-rotation or secret-re-read procedure. **Treat the secret as capture-once**: if it is
lost or believed compromised, `help@fathom.video` is the documented channel, and rotation is a cutover — every code
exchange and refresh fails until the new value is deployed. Never rotate without explicit go-ahead.

**Refresh handling is a correctness requirement, not a nicety:**

- Each refresh returns a **new** access token and a **new** refresh token; the old refresh token is invalidated.
- An unused refresh token stays valid until the user revokes access — so idle connections do not silently die, but a
  client that replays the *original* refresh token fails on the **second** refresh.
- Concurrent refreshes of the same connection: one wins, the other gets **400**. Take a per-connection lock.

**Webhook credentials are separate, and returned exactly once.** Creating a webhook returns its `id` and a `secret`
(prefixed `whsec_`). Fathom: a webhook's ID "is returned only when you create it and can't be retrieved afterward via
the API—and it isn't included in delivered payloads," and deleting via the API requires it (otherwise delete it in the
UI). **Persist both the ID and the secret at creation**; without the secret you cannot verify deliveries at all.

Report secrets once so the user can paste them into their secret store, say plainly that they are now in the
transcript, then move on.

## 8. Content, webhooks and limits — the operational shape

**Getting transcripts and summaries.** For OAuth connections, `/meetings` will not carry them; use
`GET /recordings/{recording_id}/transcript` and `GET /recordings/{recording_id}/summary`. Both endpoints have two
modes: **omit** `destination_url` and the data comes back in the response; **pass** `destination_url` and the response
is just that URL while Fathom POSTs the payload to it asynchronously. That field is *your* callback, not a download
link — a client that fetches the URL it sent is a bug waiting for the async path to be enabled.

Combined with a **fixed page size of 10** and a heavy-request budget of **30/minute (reducible to 5)**, a backfill of
transcripts is dominated by the per-recording calls, not the listing. Size it that way, honour `Retry-After` on 429,
and never re-authorize on a 429.

**Summaries:** one per recording, always the account's **default** template, always Markdown, not selectable via the
API.

**Downloads:** `POST /recordings/{recording_id}/download` starts async generation; poll the status endpoint or supply a
`destination_url`. Signed URLs expire **~24 hours** after generation, downloads are private to the API client that
created them, and "limited-access shares get **403 Forbidden**" — downloading needs more than view access.

**Webhooks.** Create with `POST /webhooks`: `destination_url` plus `triggered_for` (at least one of `my_recordings`,
`shared_external_recordings`, `my_shared_with_team_recordings`, `shared_team_recordings`), and **at least one** of
`include_transcript`, `include_crm_matches`, `include_summary`, `include_action_items` must be true. Behaviour worth
designing for:

- **Webhooks are tied to summary generation** — "no post-call summary means no webhook," which is why a 30-second test
  call never fires one. Fathom's own test advice is to record a brief ~2-minute meeting.
- **One event per new meeting, fired when content is first ready.** No later event if the transcript, summary or the
  call's visibility changes afterwards — "Poll the API if you need later updates." Visibility is evaluated at the
  moment the call finalizes.
- **Retries happen on non-2xx or timeout**, with the same `webhook-id` header — dedupe on it. There is no manual
  re-send.
- **Verification:** headers `webhook-id`, `webhook-timestamp`, `webhook-signature`. Sign `${id}.${timestamp}.${body}`
  over the **raw** body with HMAC-SHA256, keyed by the base64-decoded portion of the secret **after** the `whsec_`
  prefix, base64 the result, compare constant-time against each space-delimited signature with its `v1,` prefix
  stripped, and reject timestamps outside ~5 minutes.
- **No custom headers** can be added to outgoing deliveries, and **the payload does not say which user it belongs to**
  — Fathom's guidance is to "route each user's webhooks to a separate, user-specific destination URL rather than a
  shared endpoint." A per-connection callback path is the design that works.

**Retention.** By default Fathom keeps recordings until someone deletes them. **Retention policies are Enterprise-only,
are not self-serve** (arranged through `help@fathom.video`), and are **one policy per team, applied to all calls**;
once active, "any recording older than the set period will be permanently deleted." So transcripts do not expire on a
universal schedule — but on an Enterprise customer with a policy, history silently truncates, and a resync will not
bring it back. Ask before promising a customer a permanent archive.

> ### Product note — how this platform's connector uses Fathom (as of 2026-09-20)
>
> Dated facts, not a live reading. Confirm with the connector's owner before acting on them.
>
> - The connector supports **both** credential types: an API key sent as `X-Api-Key`, and OAuth2 bearer tokens. Its
>   customer-facing instruction for the key route points at the API Access area of Fathom user settings.
> - API base `https://api.fathom.ai/external`, cursor pagination on `next_cursor` over an `items` array, page size 10 —
>   matching Fathom's documented maximum.
> - It requests the `public_api` scope for its meeting and directory reads, exchanges and refreshes with
>   `client_id`/`client_secret` in a form-encoded body (no Basic auth), and stores a bearer token.
> - Its configured authorize **and token** hosts are on `fathom.video`, while Fathom documents the token endpoint on
>   `api.fathom.ai`. Both hosts answered on 2026-09-20 — raise it with the owner rather than assuming either is wrong.
> - It reads meetings (surfaced both as calendar events and as recordings), teams and team members. Because Fathom has
>   no single-meeting GET, it re-lists a ±2-minute `created_at` window to resolve one record — which spends the global
>   limit on every single-record read.
> - It fetches transcripts per recording from the recordings transcript endpoint — the heavy class (§8).
> - It subscribes one webhook per connection with **all four** trigger scopes and summary+transcript included, and
>   deletes by the ID returned at creation.
>
> **Raise with the owner before registering anything:**
>
> 1. **One production redirect per app** (§4) versus four regional callbacks — this is an app-count decision, not a
>    form field.
> 2. The **webhook secret returned at creation is not retained**, so deliveries cannot be HMAC-verified; the callback
>    is effectively an open ingest endpoint (§7, §8).
> 3. Two of the four trigger scopes are **Team Plans only** (§6) — a solo customer's subscription may be rejected.
> 4. **Summaries never arrive on list reads** (the list call does not request them, and OAuth connections could not get
>    them there anyway), and the dedicated summary endpoint is not called — so summary data appears only in webhook
>    payloads (§8).
> 5. The transcript path treats a returned `destination_url` as something to GET, whereas that field is the callback
>    URL Fathom posts to when you supply one (§8).

## 9. Verify end-to-end

Authorizing on the account that registered the app proves very little here. Test the path a customer takes:

1. Authorize from a **second, unrelated** Fathom account through the platform's real connect flow, using the region
   whose client ID you configured.
2. Confirm the token response carries **both** an access token and a refresh token.
3. Force a refresh, then force a **second** refresh using the token the first one returned. That is what catches a
   client that ignores rotation.
4. Fire **two refreshes concurrently** if the platform has multiple workers — one should 400. Confirm the lock.
5. List meetings, then fetch **one** transcript from `/recordings/{id}/transcript`. On an OAuth connection, confirm you
   never rely on `include_transcript`/`include_summary`.
6. On a **multi-user** test account: connect as a plain user, count the meetings; change that user's view access to all
   teams' calls; re-run and compare. That is the empirical answer to §6 for OAuth.
7. Record a ~2-minute real meeting and confirm the webhook arrives, the signature verifies, and the `webhook-id`
   deduplicates a retry.

| Symptom | Cause |
| --- | --- |
| Connection returns only the connecting user's meetings | Working as documented — that user's `view_access` is `own_meetings`; org-wide needs an admin with view access to all shared calls (§6) |
| Some meetings never appear, even for an admin | Private, unshared calls are host-only and no credential reaches them (§6) |
| Second refresh fails, first one worked | Client replayed the original refresh token instead of the rotated one (§7) |
| `400` on refresh under load | Two workers refreshed one connection concurrently; take a per-connection lock (§7) |
| Transcript/summary empty on an OAuth connection | `include_transcript`/`include_summary` are unavailable to OAuth apps — use the `/recordings` endpoints (§8) |
| `429` that clears then returns quickly | Heavy-request budget (30/60s, reducible to 5/60s) on the recordings endpoints, not the global limit (§8) |
| `403` on the users/permissions endpoint | Caller is not an `account_admin` (§6) |
| `403` on a download | Limited-access share; downloading needs more than view access (§8) |
| Download URL stops working overnight | Signed URLs expire ~24h; request a new download (§8) |
| Webhook never fires after a short test call | No post-call summary was generated, so no webhook — record ~2 minutes (§8) |
| Webhook fires once, later edits never arrive | By design; content changes and visibility changes do not re-fire — poll (§8) |
| Webhook subscription rejected for a small customer | Team-Plan-only trigger scopes requested on a non-team plan (§6) |
| Authorization succeeds but the callback is rejected | Wrong region's app: a production redirect lives on exactly one app (§4) |
| A recording ID from a Fathom call URL 404s | The number in a call URL is not the API's `recording_id`; find it via the meetings list (Platform state) |
| Key that worked yesterday now 4xx | The Fathom user was deactivated or removed from the team (§1) |

## 10. Hand off — never commit the secret

- **Do not** write the client secret or a webhook secret into source control, a test, a fixture, a committed `.env`, a
  ticket, a PR body or a chat channel. Values go to the user, for their secret store.
- If a code change is needed (a callback host, refresh-token rotation, a refresh lock, webhook signature verification),
  keep it secret-free and say what the human must set out of band.
- Close with: app name(s); which Fathom account owns them; **each** client ID labelled with the callback it serves;
  where each secret was delivered; the authorize/token endpoints and the API base; the scope (`public_api`); the
  refresh-rotation and locking requirement; where webhook IDs and secrets are stored; and anything left for the user.

## Stop and ask

Hand back to a human rather than guessing when: the platform serves more than one production callback and nobody has
agreed to **multiple apps** (§4); the client does not store **rotated** refresh tokens or has no refresh lock (§7); a
customer has been promised **org-wide** meeting coverage and nobody has confirmed an admin with all-teams view access
will be the connecting user (§6); webhook deliveries are being accepted **without signature verification** (§7); the
customer is on Enterprise with a **retention policy** and expects a permanent archive (§8); the registration form does
not match §3; or anything in **Platform state** no longer holds.

## References

Official Fathom pages only. Every URL verified to return HTTP 200 on 2026-09-20.

- Developer docs home — https://developers.fathom.ai/
- Quickstart (API key, key scoping, pagination, filters) — https://developers.fathom.ai/quickstart
- Building with OAuth (registration, review, featured at 20+ users) — https://developers.fathom.ai/oauth
- SDK OAuth guide (token endpoint, grants, rotation, scope, token-endpoint rate limit) — https://developers.fathom.ai/sdks/oauth
- API overview and rate limiting (global, heavy, download, OAuth) — https://developers.fathom.ai/api-overview
- Webhooks (creation, verification algorithm, headers) — https://developers.fathom.ai/webhooks
- FAQ (redirect URIs, refresh tokens, permissions, org access, webhook behaviour) — https://developers.fathom.ai/faq
- Changelog — https://developers.fathom.ai/changelog
- Documentation index — https://developers.fathom.ai/llms.txt
- OpenAPI specification — https://developers.fathom.ai/api-reference/openapi.yaml
- List meetings (filters, `include_*`, OAuth restriction) — https://developers.fathom.ai/api-reference/meetings/list-meetings
- Get transcript — https://developers.fathom.ai/api-reference/recordings/get-transcript
- Get summary — https://developers.fathom.ai/api-reference/recordings/get-summary
- Request a download (access rules, ~24h URLs) — https://developers.fathom.ai/api-reference/recordings/request-a-download
- Get download status — https://developers.fathom.ai/api-reference/recordings/get-download-status
- List users and their permissions (admin-only; `view_access` levels) — https://developers.fathom.ai/api-reference/users/list-users-and-their-permissions
- List teams — https://developers.fathom.ai/api-reference/teams/list-teams
- List team members — https://developers.fathom.ai/api-reference/team-members/list-team-members
- Create a webhook (trigger scopes, secret, ID) — https://developers.fathom.ai/api-reference/webhooks/create-a-webhook
- Delete a webhook — https://developers.fathom.ai/api-reference/webhooks/delete-a-webhook
- New meeting content ready (webhook payload) — https://developers.fathom.ai/api-reference/webhook-payloads/new-meeting-content-ready
- Partner example: Pylon's OAuth and webhook wiring — https://developers.fathom.ai/inspiration/pylon
- OAuth app registration form (sign-in required) — https://fathom.video/marketplace_applications/new
- User settings, API Access section (API keys, webhooks) — https://fathom.video/customize
- Help centre: Public API (user-level keys, 60 calls/minute) — https://help.fathom.video/en/articles/8368641
- Help centre: understanding permissions (settings access vs view access) — https://help.fathom.video/en/articles/10783489
- Help centre: retention policies (Enterprise-only, not self-serve) — https://help.fathom.video/en/articles/6057089
- Fathom integrations listing page — https://www.fathom.ai/integrations
- Fathom About Us (brand assets and boilerplate for launch) — https://www.fathom.ai/about-us