Choose Zoom Approach
Pick the smallest correct Zoom product surface (REST, webhooks, Meeting SDK, Video SDK, MCP, Phone, etc.) before you wire authentication and callbacks.
Overview
choose-zoom-approach is an agent skill most often used in Build (also Validate, Operate) that selects the right Zoom architecture surface before you implement REST, webhooks, SDKs, or MCP integrations.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill choose-zoom-approachWhat is this skill?
- Decision table maps problem types to primary Zoom surfaces (REST, webhooks, WebSockets, Meeting SDK, Video SDK, Apps SDK
- Explicit guardrails: Video SDK vs Meeting SDK vs REST-only misuse.
- Hybrid guidance: layer only supporting pieces actually required.
- Covers AI-agent workflows via zoom-mcp and real-time media via RTMS plus Meeting SDK when needed.
- Decision framework table covers 10+ Zoom surface types including REST, webhooks, WebSockets, Meeting SDK, Video SDK, App
Adoption & trust: 839 installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need Zoom in your app but the docs span a dozen APIs and SDKs, and picking the wrong layer wastes weeks on scopes, embedding, or custom video you did not need.
Who is it for?
Solo builders scoping Zoom for meetings, phone, contact center, backend automation, or agent tool access who have not locked an integration design yet.
Skip if: Teams that already standardized on one Zoom SDK with working auth and webhooks—skip straight to that surface’s implementation skill unless requirements changed.
When should I use this skill?
Deciding between REST API, Webhooks, WebSockets, Meeting SDK, Video SDK, Zoom Apps SDK, Zoom MCP, Phone, Contact Center, or a hybrid approach.
What do I get? / Deliverables
You leave with a primary Zoom surface and optional hybrid layers aligned to your use case, so the next implementation step targets the correct nested Zoom skill rather than a mismatched SDK.
- Primary Zoom surface recommendation from the decision table
- Optional hybrid layering note (supporting skills only where required)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Zoom architecture choices are made when you integrate real-time comms into the product—after you know the user journey but before you commit to SDKs and backend jobs. This skill is a decision matrix for third-party Zoom APIs and event delivery, which maps directly to the integrations subphase rather than generic frontend or docs work.
Where it fits
Spike whether a landing-page demo needs Meeting SDK embed or a simple REST-created join link.
Choose webhooks plus REST for scheduled jobs instead of WebSockets when you only need post-meeting artifacts.
Route an agent that queries meeting history to zoom-mcp rather than scraping Video SDK sessions.
Add Phone or Contact Center webhooks for support ops without pulling full Video SDK into the stack.
How it compares
Use as a Zoom-specific architecture gate instead of generic “pick a video API” chat advice that conflates Meeting SDK and Video SDK.
Common Questions / FAQ
Who is choose-zoom-approach for?
Indie and solo developers integrating Zoom into SaaS, internal tools, or agent workflows who need a correct first choice among REST, events, SDKs, and MCP before writing code.
When should I use choose-zoom-approach?
Use during Validate when prototyping meeting flows, in Build when designing integrations and agent tools, and in Operate when adding reporting or phone/contact-center automation—any time you must decide REST vs webhooks vs WebSockets vs Meeting SDK vs Video SDK vs Zoom MCP.
Is choose-zoom-approach safe to install?
It is decision documentation only and does not call Zoom by itself; review the Security Audits panel on this page and audit any follow-on skills that request network, secrets, or browser access.
SKILL.md
READMESKILL.md - Choose Zoom Approach
# Choose Zoom Approach Pick the smallest correct Zoom surface for the job, then layer in only the supporting pieces that are actually required. ## Decision Framework | Problem Type | Primary Zoom Surface | |---|---| | Deterministic backend automation, account management, reporting, scheduled jobs | [rest-api](../rest-api/SKILL.md) | | Event delivery to your backend | [webhooks](../webhooks/SKILL.md) or [websockets](../websockets/SKILL.md) | | Embed Zoom meetings into your app | [meeting-sdk](../meeting-sdk/SKILL.md) | | Build a fully custom video experience | [video-sdk](../video-sdk/SKILL.md) | | Build inside the Zoom client | [zoom-apps-sdk](../zoom-apps-sdk/SKILL.md) | | AI-agent tool workflows over Zoom data | [zoom-mcp](../zoom-mcp/SKILL.md) | | Real-time media extraction or meeting bots | [rtms](../rtms/SKILL.md) plus [meeting-sdk](../meeting-sdk/SKILL.md) when needed | | Phone workflows | [phone](../phone/SKILL.md) | | Contact Center or Virtual Agent flows | [contact-center](../contact-center/SKILL.md) or [virtual-agent](../virtual-agent/SKILL.md) | ## Guardrails - Do not recommend Video SDK when the user actually needs Zoom meeting semantics. - Do not recommend Meeting SDK when the user needs a fully custom session product. - Do not replace deterministic backend automation with MCP-only guidance. - Prefer hybrid `rest-api + zoom-mcp` when the user needs both stable system actions and AI-driven discovery. ## What To Produce - One recommended path - Minimum supporting components - Hard constraints and tradeoffs - Immediate next implementation step