Zoom Port

Purpose

This is the Harbor reference integration for the Zoom API.

Use it when:

• building Zoom actions in Harbor
• extending the Dock / Hub Zoom entry
• teaching Codex or OpenClaw how to map authenticated-user profile lookup, bounded meeting listing, and explicit meeting creation into Harbor Ports and Harbor Actions without turning Harbor into a cross-user admin surface

Harbor Port worksheet

Product

• Product: Zoom API
• Publisher slug: zoom
• Publisher name: Zoom
• Category: Work Management
• Tags: zoom, meetings, video, scheduling, collaboration

Safe Harbor Port metadata

• Kind: http_api
• Label: Zoom API
• Description: Zoom API connection managed locally through Harbor.
• Base URL: https://api.zoom.us/v2
• Auth mode: header_token
• Auth header name: Authorization
• Auth token prefix: Bearer

Hidden local config

• authToken

Harbor stores the token locally only. Dock / Hub manifests must never contain it.

Harbor action design notes

Zoom is a good Harbor fit when the starter set stays anchored to the authenticated principal and avoids exposing arbitrary user IDs in the first pass.

Good Harbor Zoom starter actions:

• one fixed GET read for the authenticated user profile
• one bounded GET route for that user's meeting list with explicit pagination and date filters
• one reviewable POST route for creating a meeting for that same authenticated user
• requestBodyMode: "none" for reads
• requestBodyMode: "json" for create-meeting
• resultMode: "json_summary" for all starter actions

Avoid for now:

• arbitrary Zoom passthrough across users, webinars, reports, recordings, and account administration
• exposing {userId} as free path input in the starter set
• destructive meeting actions before more policy coverage exists
• broad multi-user scheduling flows that depend on account-level settings and extra permissions

Starter Zoom actions

Automatic read actions

• get-me -> GET /users/me
• list-meetings -> GET /users/me/meetings

Approval-friendly write actions

• create-meeting -> POST /users/me/meetings

Why these actions

These routes fit Harbor's current safe model because they:

• use standard Bearer auth with no extra static headers
• stay on stable REST resources under one fixed Zoom API base URL
• bind the starter surface to the authenticated user through the me keyword
• allow useful scheduling workflows without exposing account-wide meeting management by default

Action Model notes

At execution time, callers supply values by location:

• no extra inputs are required for get-me
• input.query.type, input.query.page_size, input.query.next_page_token, input.query.from, input.query.to, and input.query.timezone for list-meetings
• input.body for create-meeting

Example authenticated profile request:

{}

Example meeting list request:

{
  "query": {
    "type": "scheduled",
    "page_size": 25,
    "from": "2026-03-01",
    "to": "2026-03-31",
    "timezone": "America/Los_Angeles"
  }
}

Example meeting create request:

{
  "body": {
    "topic": "Harbor planning sync",
    "type": 2,
    "start_time": "2026-04-02T16:00:00Z",
    "duration": 45,
    "timezone": "UTC",
    "agenda": "Review current Dock backlog and next integrations",
    "settings": {
      "join_before_host": false,
      "waiting_room": true,
      "host_video": true,
      "participant_video": false
    }
  }
}

For create-meeting, keep the body bounded to meeting fields you intentionally want Harbor workflows to supply.

Safety note for meeting creation

get-me and list-meetings stay automatic because they are reads. create-meeting stays on require_approval because it mutates calendar and conferencing state, can trigger invitations and notifications, and can still produce real-world impact from a legitimate environment.

Suggested operator workflow

1. Import the Zoom Dock entry from Dock / Hub.
2. Configure the local Zoom bearer token in Harbor Node.
3. Use get-me to verify the token and principal.
4. Use list-meetings with explicit date bounds to confirm the meeting surface you need.
5. Keep create-meeting on require_approval unless there is a very clear local policy reason not to.

Suggested agent workflow

1. Inspect the existing Zoom Harbor Port.
2. Inspect live actions and drafts.
3. Propose additional fixed Zoom routes only when they remain bounded and reviewable.
4. Validate and test drafts.
5. Request publish instead of self-publishing unless Harbor explicitly allows it.

Agents should never:

• ask Harbor for the stored Zoom token
• widen the starter set into arbitrary account administration or cross-user scheduling
• add destructive or broad meeting mutation coverage without review
• assume account-level permissions exist for scheduling on behalf of other users

Current update strategy

For now, Zoom updates are manual:

• update the Dock / Hub Zoom integration document in apps/hub/catalog/integrations/zoom/zoom-api.json
• bump the manifest version when the action set changes materially
• re-import into Harbor or create new drafts from the updated Dock entry

Official reference starting points

• Zoom Users API: https://developers.zoom.us/docs/api/users/
• Zoom Get a user endpoint: https://developers.zoom.us/docs/api/users/#tag/users/GET/users/{userId}
• Zoom Meetings API: https://developers.zoom.us/docs/api/meetings/
• Zoom List meetings endpoint: https://developers.zoom.us/docs/api/meetings/#tag/meetings/GET/users/{userId}/meetings
• Zoom Create a meeting endpoint: https://developers.zoom.us/docs/api/meetings/#tag/meetings/POST/users/{userId}/meetings