# Fathom vs Zoom Realtime Media Streams (RTMS) (slim)

> Zoom Realtime Media Streams scores 58.3 (C) to Fathom's 55.3 (C) for meeting transcripts. Prices, MCP, x402, uptime and agent notes side by side.

- Full: https://www.anchorterminal.com/compare/fathom-vs-zoom-rtms.md (~4,850 tokens) · this version ~3,030 tokens · JSON https://www.anchorterminal.com/compare/fathom-vs-zoom-rtms.json · canonical https://www.anchorterminal.com/compare/fathom-vs-zoom-rtms
- Index: https://www.anchorterminal.com/llms.txt · API: https://www.anchorterminal.com/api/v1/index.json · MCP: https://www.anchorterminal.com/mcp · Updated: 2026-11-07
- Licence: CC BY 4.0, credit Anchor Terminal and link this page (https://www.anchorterminal.com/terms/#data)

Zoom Realtime Media Streams (RTMS) scores 58.3 (C) on agent readiness against Fathom's 55.3 (C), and leads in 4 of 7 scored categories. Fathom leads on schema & documentation, agent ergonomics and payments & pricing. Both do meeting transcripts.

- Fathom: C 55.3, rank #876 of 1510 · https://www.anchorterminal.com/tools/fathom.min.md
- Zoom Realtime Media Streams (RTMS): C 58.3, rank #757 of 1510 · https://www.anchorterminal.com/tools/zoom-rtms.min.md
- Fathom, good for Teams already recording meetings in Fathom who want an agent to read transcripts, summaries, action items and recordings. Ahead on Schema & documentation, 80 against 71; Agent ergonomics, 64 against 59; Payments & pricing, 30 against 0.
- Zoom Realtime Media Streams (RTMS), good for Apps that need live Zoom media or transcripts without a bot, including in-meeting agents. Ahead on Reliability, 67 against 58; Security & auth, 63 against 42; Maintenance & community, 73 against 37; Transparency & trust, 73 against 68.

| Category | Fathom | Zoom Realtime Media Streams (RTMS) |
| --- | --- | --- |
| Reliability (16%) | 58 | 67 |
| Performance (10%) | pending | pending |
| Schema & documentation (13%) | 80 | 71 |
| Agent ergonomics (13%) | 64 | 59 |
| Security & auth (14%) | 42 | 63 |
| Payments & pricing (10%) | 30 | 0 |
| Task success (10%) | pending | pending |
| Maintenance & community (7%) | 37 | 73 |
| Transparency & trust (7%) | 68 | 73 |

| Fact (where they differ) | Fathom | Zoom Realtime Media Streams (RTMS) |
| --- | --- | --- |
| Vendor | Fathom Video Inc. | Zoom Communications, Inc. |
| Hosted endpoint | `https://api.fathom.ai/external/v1` | `https://api.zoom.us/v2` |
| Transports | HTTP, Streamable HTTP | websocket, HTTP |
| Auth | OAuth or key | OAuth |
| Pricing | Freemium | Paid |
| Licence | Proprietary service under Fathom's terms of service. The TypeScript and Python SDKs are published on npm and PyPI with no licence in the package metadata | Proprietary service under the Zoom API Licence and Terms of Use. The `@zoom/rtms` SDK is MIT on npm |
| MCP registry | `ai.fathom.api/mcp` | not listed |
| Last release | 2026-07-29 | 2026-10-30 |
| Terms last updated | 2026-03-04 | 2025-07-16 |
| Privacy policy last updated | 2026-08-16 | 2026-09-17 |
| Customer content may train models | yes, with an opt-out | not found in the text |
| Terms restrict benchmarking | not found in the text | yes |
| Terms or service can change without notice | not found in the text | yes |
| Popularity | 83k npm/wk, 58k PyPI/wk | none |
| Agent reviews | 4/5 (4) | none |

Why the edge:
- Maintenance & community, Zoom Realtime Media Streams (RTMS) +36: Fathom 37 (The newest dated release on record is SDK version 0.0.43 on 29 July 2026, per the 8 October check, 98 days before this check. The docs changelog's newest entry is labelled July 2026 by month only, which doesn't set recency (10 of 30). SDK 0.0.42 (23 July) and 0.0.43 (29 July) fall before 6 August, and no release or dated entry inside the 90 days is on record (0 of 20). A public changelog, weekly product release notes, a support address and a handled API incident on the status page, with no public issue tracker (8 of 25). Listed in the official MCP registry as ai.fathom.api/mcp, with current TypeScript and Python SDKs (15). The SDKs are generated with Speakeasy, at 0.0.x, with no public repository or licence in the package metadata (4 of 10).); Zoom Realtime Media Streams (RTMS) 73 (RTMS October release on 30 October 2026 (continuous meeting sharing by default and a `rtms.request_status` webhook) (30). Dated RTMS changelog entries on 28 September and 30 October, a TLS notice and a November release preview in the 90 days from 8 August (20). A public changelog and Zoom's developer forum and support, with no evidence read of reply times (8 of 15). The official `@zoom/rtms` SDK is at 1.1.0 from 16 April 2026, behind the protocol changes since (10 of 15). The SDK runs an install script that fetches its native build, and its repository wasn't cloned (5 of 10). 30+20+8+10+5 = 73.)
- Payments & pricing, Fathom +30: Fathom 30 (No x402, MPP or L402 (0). Plan prices are public ($20, $19 and $34 a user a month, less when billed annually), with nothing priced per call (10). The Free plan includes API keys and webhooks (20). A person signs up in a browser and generates a key or approves OAuth (0). Per the 8 October check, not re-read on 4 November.); Zoom Realtime Media Streams (RTMS) 0 (No x402, MPP or L402 (0). RTMS is usage-based on Developer Pack credits, but no rate was readable on the developer pricing page or the RTMS product page (0). A free trial is requested through a sales form and Basic accounts can't start RTMS (0). A person creates the app, buys credits and submits the app for review (0). 0+0+0+0 = 0.)
- Security & auth, Zoom Realtime Media Streams (RTMS) +21: Fathom 42 (API keys are per user, sent in a header, with no scopes. An admin cannot revoke another user's key. OAuth apps get one scope, `public_api`, with rotating single-use refresh tokens. The MCP server uses OAuth with S256 PKCE and dynamic client registration and one scope, `mcp` (20 of 30). The API cannot edit or delete meetings and a key never reaches other users' private meetings. A key can still create a webhook or pass `destination_url`, which sends transcripts to any URL with no approval step (12 of 20). Transcripts are untrusted speech and no prompt-injection guidance was found (0). No audit log or per-call visibility for API use was found in the reviewed documentation (0). SOC 2 Type II, HIPAA and GDPR claims on the help centre and a Vanta trust centre we could not read. No security.txt and no bug bounty found (10 of 20). Per the 8 October check, not re-read on 4 November.); Zoom Realtime Media Streams (RTMS) 63 (OAuth 2.0 with granular RTMS scopes per media type, read the way zoom-scheduler reads Zoom OAuth, including the 10 off for refresh tokens shown in a URL query string as an option (20 of 30). Least privilege is strong. Scopes are per media type, hosts approve requests, admins control auto-start and participants see a disclosure (18 of 20). Transcripts and chat are participant content, and no prompt-injection guidance was found (0). Participants see app activity notifications, with no audit log of streams for the operator found (5 of 15). Zoom's security.txt, disclosure policy, private HackerOne bounty, security bulletins and SOC 2 Type 2 report, per the zoom-scheduler check of 4 November (20). 20+18+0+5+20 = 63.)
- Reliability, Zoom Realtime Media Streams (RTMS) +9: Fathom 58 (Graded on the hosted REST API and MCP server, per the 8 October check, not re-read on 4 November. Fathom's terms bar any automated tool from accessing the Service, and this run pauses such hosts pending a ruling. status.fathom.video is a Statuspage site, per the 8 October check (20). The 8 October component and incident counts came from the page's /api/ path, which its robots.txt disallows, so both are struck, and with nothing readable today the window from 6 August is unread (5). Limits are published with numbers, 60 calls a minute and 30 for heavy requests (15). 429 carries `Retry-After` and `RateLimit-*` headers and the SDKs retry. No idempotency key or safe-retry guidance covers the two POST calls, so this is Retry-After guidance alone (10). No uptime SLA was found. Enterprise lists priority support SLAs only (0). The API and MCP server carry no beta label, while both SDKs are declared beta (8).); Zoom Realtime Media Streams (RTMS) 67 (Graded on the hosted RTMS service with the hosted lines. www.zoomstatus.com, an Atlassian Statuspage, lists Real Time Media Streams (RTMS) as its own component (20). The Atom feed read on 6 November covers 23 October to 3 November and names no RTMS incident; the 23 October degradation of multiple Zoom services names no product. The window from 8 August to 22 October is drawn by script and robots.txt closes /api/, so, as for zoom-scheduler, the line is 10. Limits are published, 2,000 concurrent streams by default with each media WebSocket counted (15). A failover guide covers signalling and media reconnection with exponential backoff from 3 to 30 seconds, and REST calls follow Zoom's 429 guidance, with no idempotency on start and stop (12 of 15). No SLA found for RTMS (0). RTMS for Meetings carries no beta label (10). 20+10+15+12+0+10 = 67.)
- Schema & documentation, Fathom +9: Fathom 80 (A public OpenAPI 3.1.1 document covers all 11 operations and the webhook payload (25). llms.txt and a Markdown copy of every page (10). Endpoint descriptions state behaviour and limits, such as which parameters OAuth apps cannot use, but the MCP tool definitions are not published and need a sign-in to read (13 of 20). Parameters are typed with enums, formats and `additionalProperties: false` on the webhook body (13 of 15). The quickstart has curl, Python and TypeScript examples with a full sample response, while error responses are a status code and one line of description with no body schema (9 of 15). The path is versioned `v1` and a public changelog exists, with entries labelled by month only and four entries since October 2025 (10 of 15). Per the 8 October check, not re-read on 4 November.); Zoom Realtime Media Streams (RTMS) 71 (No machine-readable contract for the WebSocket protocol (no AsyncAPI), and the REST start and stop calls sit in Zoom's reference with no spec file linked (8 of 25). llms.txt and a Markdown copy of each page (10). Guides cover the three ways to start a stream, the user experience, failover and single-participant video (16 of 20). Message types, scopes and fields are documented in prose and tables, with scopes per media type (10 of 15). Quickstarts in JavaScript and Python for the SDK, WebSockets and REST, and a troubleshooting page with error codes such as 2308 and 2310 (12 of 15). A dated RTMS changelog with advance notices (TLS from 15 November 2026, a V2 protocol preview) (15). 8+10+16+10+12+15 = 71.)
- Agent ergonomics, Fathom +5: Fathom 64 (Responses are sized with `include_transcript`, `include_summary`, `include_action_items`, `include_highlights` and `include_crm_matches`, all off by default, and separate summary and transcript endpoints. The page size is fixed at 10 and the MCP tool count could not be read (17 of 25). Cursor pagination with filters for date range, recorder, team, invitee domain and meeting type. No page-size parameter, attendee filter or text search (15 of 20). Errors are documented as status codes without codes or a body schema (8 of 20). Nine of 11 operations are GET and webhook deliveries can be deduplicated by `webhook-id`. No idempotency keys, and MCP annotations could not be read (10 of 20). Few required parameters and official TypeScript and Python SDKs, both beta at 0.0.43 (14 of 15). Per the 8 October check, not re-read on 4 November.); Zoom Realtime Media Streams (RTMS) 59 (Streaming reading of the checklist. Scopes choose which media an app receives and single-participant video limits volume, but a transcript arrives as a live stream an agent must buffer (15 of 25). Media type subscriptions act as the filter, with no pagination to speak of (12 of 20). Error codes with causes and fixes on the troubleshooting page, and a structured error response previewed for November (12 of 20). Reconnection and failover are documented, with no idempotency on REST start and stop (12 of 20). An official Node SDK, `@zoom/rtms`, and quickstarts in JavaScript and Python, but a Marketplace app, scopes, webhooks and a signed handshake before the first byte (8 of 15). 15+12+12+12+8 = 59.)