Zoom Cobrowse Sdk
Integrate Zoom Cobrowse with CDN or npm, server-issued JWTs, and customer/agent role sessions for guided support in your app.
Overview
Zoom Cobrowse SDK is an agent skill for the Build phase that documents Cobrowse distribution, server JWT auth, and the customer/agent session lifecycle.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill zoom-cobrowse-sdkWhat is this skill?
- Choose CDN vs npm based on UI control, agent hosting, and CSP constraints
- Server-only JWT using SDK key/secret—short-lived tokens, never expose secret client-side
- Two roles: `role_type=1` customer and `role_type=2` agent with separate JWTs
- Session lifecycle: init → role tokens → customer PIN → agent join → connected/end events
- Typical server objects: customer session record with `session_id`, PIN, status, and expiry
- Two role types: role_type=1 customer, role_type=2 agent
Adoption & trust: 830 installs on skills.sh; 19.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want guided co-browse in your product but are unsure how to issue JWTs, split customer vs agent roles, and manage PIN sessions without exposing secrets.
Who is it for?
Builders adding Cobrowse to a web app with separate customer and agent experiences and strict CSP or self-hosted agent UI.
Skip if: In-meeting Zoom Apps using `@zoom/appssdk` only, or teams that need Cobrowse without any backend token endpoint.
When should I use this skill?
You are integrating Zoom Cobrowse and need JWT, CDN/npm choice, and customer/agent session lifecycle guidance.
What do I get? / Deliverables
You can implement init-on-both-sides, server JWT generation, PIN handoff, and role-specific joins aligned with Zoom’s authorization model.
- Server JWT issuance design
- Session + PIN lifecycle implementation outline
Recommended Skills
Journey fit
Cobrowse is implemented when you wire SDK init, PIN sessions, and server tokens into your product—core build-time integration work. Fits integrations: Cobrowse SDK, JWT auth, and two-role session lifecycle rather than pure UI or ops monitoring.
How it compares
Cobrowse session and JWT integration skill—not Zoom Apps in-meeting architecture or a generic screen-share MCP tool.
Common Questions / FAQ
Who is zoom-cobrowse-sdk for?
Solo builders implementing Zoom Cobrowse with server-side JWTs and customer/agent pages in their support or onboarding stack.
When should I use zoom-cobrowse-sdk?
In Build when you choose CDN/npm, wire server token issuance, and implement PIN-based sessions with `role_type` 1 and 2 before going live.
Is zoom-cobrowse-sdk safe to install?
Follow server-only secret handling in the skill; confirm package trust via the Security Audits panel on this Prism catalog page.
SKILL.md
READMESKILL.md - Zoom Cobrowse Sdk
# Distribution Methods Zoom Cobrowse supports CDN and npm-based integrations, depending on your architecture. Choose based on: - how much UI control you need, - whether you host your own agent experience, - your deployment and CSP constraints. See: - [Get Started](../get-started.md) - [Features (official)](../references/features-official.md) # JWT Authentication Generate Cobrowse JWTs server-side using your SDK key and SDK secret. Guidelines: - Never expose SDK secret client-side. - Issue short-lived tokens. - Generate different tokens for customer and agent roles. See: - [Authorization (official)](../references/authorization-official.md) - [Get Started](../references/get-started-official.md) # Session Lifecycle Typical flow: 1. Initialize SDK on customer and agent pages. 2. Generate role-specific JWT tokens. 3. Customer starts a session and receives a PIN. 4. Agent joins using the PIN. 5. Session events track connected/disconnected/end states. See: - [Get Started](../get-started.md) - [Features (official)](../references/features-official.md) # Two Roles Pattern Zoom Cobrowse uses two roles: - `role_type=1`: customer session - `role_type=2`: agent session Use separate JWTs for each role and keep token generation on the server. ## What Is Usually Created In most real implementations, you create these objects in order: 1. **Customer session record** (server-side) - `session_id` - generated PIN - status (`active`/`revoked`) - expiry timestamp 2. **Customer token** (`role_type=1`) - used by customer browser SDK to start/share session 3. **Agent token** (`role_type=2`) - created after PIN validation - used to load agent desk iframe or custom agent UI ## PIN Source of Truth In practice, the PIN you should hand to agents is the value emitted by customer SDK event: - `session.on("pincode_updated", ...)` Do not rely on placeholder/provisional PIN values from pre-start backend records for user-facing flows. Always show one clearly labeled PIN in UI (for example, "Support PIN") and reuse that same value in agent links. ## Recommended Endpoint Split - `POST /api/customer/start` -> create session + customer token + PIN - `POST /api/agent/connect` -> validate PIN + issue agent token - `POST /api/session/revoke` -> end session - `GET /api/session/list` -> operational visibility See: - [Get Started](../get-started.md) - [Authorization (official)](../references/authorization-official.md) # Agent Integration Agent integration joins an active customer session by PIN using an agent-role token. See: - [Get Started](../get-started.md) - [Authorization (official)](../references/authorization-official.md) # Annotation Tools Enable annotation settings during SDK initialization to allow drawing and highlighting. See: - [Features (official)](../references/features-official.md) - [API (official)](../references/api-official.md) # Auto-Reconnection Implement reconnection handlers for transient network interruptions and refresh scenarios. See: - [Get Started](../get-started.md) - [Features (official)](../references/features-official.md) # BYOP Custom PIN Bring Your Own PIN mode lets you control PIN generation/format in your own application flow. See: - [Authorization (official)](../references/authorization-official.md) - [Get Started](../get-started.md) # Customer Integration Customer-side integration should initialize the SDK, fetch a server-generated token, then start a session. See: - [Get Started](../get-started.md) - [API (official)](../references/api-official.md) # Multi-Tab Persistence Cobrowse sessions can continue across tabs when configured correctly and browser constraints are met. See: - [Features (official)](../references/features-official.md) - [Get Started](../get-started.md) # Privacy Masking Configure masking selectors for sensitive customer fields so agents cannot view protected values. See: - [Features (official)](../references/features-official.md) - [Get Star