setup-zoom-websockets — Codex command: what it does, how to install
Implements a persistent Zoom WebSocket stream with connection lifecycle, heartbeat, and reconnection logic instead of HTTP webhooks.
~/.codex/prompts/setup-zoom-websockets.mdWhat setup-zoom-websockets does
This command guides the agent through building or fixing a Zoom WebSocket client. The preflight check inspects existing connection logic, verifies firewall or latency constraints, then defines which backend service owns the connection. A plan lists affected files and verification steps before editing starts.
Implementation focuses on lifecycle management: heartbeats, exponential backoff, and clean shutdown handling. Streamed events are normalized into internal project formats, with observability added for dropped packets or disconnects.
If standard HTTP callbacks handle your workload without firewall hurdles, switching to /setup-zoom-webhooks saves operational overhead. Checking reconnect behavior before deploying the stream prevents silent connection drops.
What it helps with
- replace webhook callbacks with persistent Zoom event streaming
- add heartbeat and exponential backoff to a socket client
- normalize incoming Zoom socket events into project contracts
- track connection drops and delayed messages
Example prompts for the agent
- Run setup-zoom-websockets to build a persistent Zoom event consumer in our backend
- Fix the reconnect and heartbeat handling in our Zoom WebSocket client
- Implement Zoom WebSocket event normalization and observability for connection drops
How to install setup-zoom-websockets
Manually: put the files in place
~/.codex/prompts/setup-zoom-websockets.mdCall it with /prompts:setup-zoom-websockets. Codex marks this format deprecated in favour of skills
Manually: put the files in place
.claude/commands/setup-zoom-websockets.mdCall it with /setup-zoom-websockets. For all projects use ~/.claude/commands/
Manually: put the files in place
.github/prompts/setup-zoom-websockets.prompt.mdManually: put the files in place
.gemini/commands/setup-zoom-websockets.tomlGemini stores commands as TOML: the prompt text goes into the prompt field
Questions about setup-zoom-websockets
How do I install setup-zoom-websockets in Codex?
Save the command file to ~/.codex/prompts/setup-zoom-websockets.md. You can then call the prompt directly during Codex coding sessions.
What does setup-zoom-websockets do?
It directs Codex through auditing, planning, and coding a Zoom WebSocket integration. The workflow ensures heartbeat checks, backoff logic, and event normalization are properly handled.
When should you use webhooks instead of WebSockets?
WebSockets solve strict latency demands or inbound firewall blocks. If standard HTTP delivery meets your requirements, switching to /setup-zoom-webhooks keeps the infrastructure simpler.
Source text
setup-zoom-websockets.md · MIT
--- description: Implement or correct a Zoom WebSocket event stream with connection lifecycle, auth handling, and reconnect behavior. --- # Setup Zoom WebSockets Use this command when the integration needs persistent Zoom event delivery instead of standard webhook callbacks. ## Preflight 1. Inspect the repository for existing WebSocket clients, event consumers, connection-state handling, and auth configuration. 2. Confirm WebSockets are justified by latency, delivery model, firewall constraints, or connection semantics. 3. Identify the event types and app configuration required for the stream. 4. Confirm the owning backend or service that will manage connect, heartbeat, reconnect, and shutdown behavior. ## Plan Before making changes: - state the WebSocket event stream being implemented - list the files that will be changed - state the auth path and connection lifecycle responsibilities - state how the connection path will be verified ## Commands 1. Add or correct the WebSocket connection setup at the appropriate service layer. 2. Implement authentication, heartbeat, reconnect, backoff, and shutdown handling explicitly. 3. Normalize streamed events into the repo’s existing internal event contract where possible. 4. Add observability for connection state, reconnects, and dropped or delayed events. 5. Keep the first pass focused on one working event stream before layering in broader orchestration. 6. Avoid claiming the stream works until the connection lifecycle and event handling path are both checked. ## Verification 1. Re-read the connection manager, auth code, and event handler logic after changes. 2. Run local build or tests where available. 3. Verify the connect path, reconnect strategy, and event normalization path. 4. State any remaining blocker such as app subscription setup, token path, or network constraints. ## Summary ```text ## Result - Action: implemented or updated a Zoom WebSocket event stream - Status: success | partial | failed - Details: connection path, auth model, event handling, verification run ``` ## Next Steps - Test the stream against real events in a controlled environment. - If the connection path is healthy but event handling fails, narrow the downstream layer next. - If HTTP callbacks would be simpler and sufficient, switch to `/setup-zoom-webhooks`.
© Zoom · MIT · openai/plugins