zoom v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-zoom-s2s-oauth

Custody

customer_vault

Injection

header (Authorization)

A Zoom Server-to-Server OAuth access token, externally minted, held in the client's own secret manager. This reference defines ONE stored value and nothing else: the complete Authorization header value (scheme included), 'Bearer ' followed by the access token. The app's account ID, client ID and client secret are NOT stored under this reference — they belong under separate credential references that only the deployment's custody job may resolve. Zoom's documented flow is two-legged OAuth: the custody job POSTs to the token endpoint with grant_type=account_credentials and a Basic Authorization header built from the client ID and secret, receiving a bearer access token with a one-hour TTL (3600 seconds) and no refresh token; it stores the resulting 'Bearer <token>' value under this reference and re-runs the exchange before the hour expires. The HTTP injector injects the stored value verbatim and performs no OAuth itself — there is no execution-time derivation option. Per the retrieved documentation: multiple access tokens can be generated without invalidating previous ones — issuing a new token does NOT revoke an older one — and there is no per-token revocation, so an already-issued token is valid for up to its full hour. Deactivating or deleting the app is the documented cut-off path — tokens stop working when the app is deactivated — but the exact interaction between deactivation and an in-flight token's remaining lifetime is unspecified in the retrieved docs, so treat every issued token as live for its full hour unless the app is deactivated about any single token: on suspected exposure, deactivate the app AND treat any already-issued token as live for up to its remaining hour. Least privilege: create a dedicated Server-to-Server OAuth app per integration, grant only the scopes these capabilities require (user read, meeting read/write, cloud recording read, and recording delete only if the delete capability is enabled), and keep the app owner's own permissions minimal since scopes are authorized against them. Executor hygiene: the client secret and derived tokens must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• zoom-account (api, pii): https://zoom-api.invalid/v2

The endpoint host 'zoom-api.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the Zoom API host (api.zoom.us) before enabling, in every endpoint, in the resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step — the reserved host being allowlisted does not make an unsubstituted pack safe to enable. This pack registers only API v2 operations the retrieved Zoom developer documentation establishes: listing users, listing a user's meetings, creating, updating and deleting a meeting, listing a user's cloud recordings, and deleting a meeting's recording files. USER_ID and MEETING_ID in the endpoint paths are placeholders the deployment binds before enabling. The API's 'me' keyword is not registered guidance here: under Server-to-Server OAuth the token is an account-level credential, not an ordinary token-owner user session, so bind a concrete user ID. Zoom enforces the Server-to-Server OAuth app's scopes and admin role on every call, so a capability works only if the app carries the matching scope (for example cloud_recording:delete:meeting_recording:admin for recording deletion); the registration records the endpoint, not Zoom's authorization decision. Documented exclusions — this pack does not register: user provisioning and deprovisioning (POST /v2/users and DELETE /v2/users/{userId} — creating or deleting account members is an identity-lifecycle surface requiring its own review); webinar APIs; meeting registrant add/remove; live-meeting control and in-meeting operations; the recording download URLs themselves (downloading recording content is a bulk-content read, not registered); the meeting/webinar archiving endpoints (FINRA compliance archiving, admin-only and support-enabled); archive file deletion (DELETE /past_meetings/{meetingUUID}/archive_files exists in the retrieved documentation and is deliberately not registered); Zoom Phone, Team Chat messaging, and account settings or role management. The legacy JWT app type is retired by Zoom; this pack describes Server-to-Server OAuth only.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://developers.zoom.us/docs/api/meetings/ (retrieved 2026-09-21)
• https://developers.zoom.us/docs/api/users/ (retrieved 2026-09-21)
• https://developers.zoom.us/docs/internal-apps/s2s-oauth/ (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.