Reviewer test plan

Pixelogy for Zoom — Test plan

Effective date: May 22, 2026

This is the step-by-step test plan for Zoom Marketplace reviewers. It covers OAuth authorization, every requested scope, every visible user control, and the disconnect and denial cases. Reviewer credentials are supplied privately in the App Credentials field.

End users should read the user documentation for adding, using, and removing the app.

Overview

App Summary

Pixelogy for Zoom Meetings lets an authorized Zoom user connect a Zoom account or token-relay state to Pixelogy Control. From Pixelogy, an operator can join an approved Zoom meeting, optionally create a meeting when meeting-write is enabled, ask a customer-controlled render node to join that meeting as a visible participant, and place live Zoom participant video on managed display surfaces.

The app is intended for live production, venue display, signage, and customer-controlled meeting display workflows. Pixelogy does not provide hidden meeting monitoring, and Pixelogy does not store Zoom meeting audio or video by default.

Public Pages

App landing page: https://www.pixelogy.tech/zoom

OAuth redirect endpoint (production): https://www.pixelogy.tech/zoom/redirect

Privacy policy: https://www.pixelogy.tech/privacy

Terms: https://www.pixelogy.tech/terms

Support: https://www.pixelogy.tech/support

User documentation: https://www.pixelogy.tech/docs/zoom-meetings

Reviewer Credentials

Sensitive credentials are supplied only in the Zoom Marketplace App Credentials field. They are not included in this public document.

Provided privately for review: Pixelogy Control review URL, Pixelogy Control username, Pixelogy Control password, the review render node name shown in the Zoom node filter, and an optional Zoom test host account if Pixelogy supplies one.

Zoom reviewers can also authorize the app with their own reviewer Zoom account during the OAuth test. Reviewers do not need Pixelogy's OAuth client secret, admin-managed app secret, Server-to-Server OAuth secret, or Meeting SDK secret.

Scopes Used

user:read:token:admin

Used only when Pixelogy needs short-lived token material for a Meeting SDK join/start flow associated with the configured Zoom account user. Pixelogy calls GET /users/{userId}/token?type=zak or GET /users/{userId}/token?type=onbehalf. This supports visible render-node meeting participation and does not bypass Zoom host controls.

Disabled In Token-Only Mode

Scheduled meeting lists, upcoming meeting/calendar lists, direct GET /users/me/zak retrieval, verified profile identity display from GET /users/me, and Quick Meeting creation are not exposed unless their matching additional scopes are intentionally enabled.

Optional Expanded Scopes

If Pixelogy later enables the broader user-facing convenience workflow, user:read:user supports GET /users/me profile display, meeting:write:meeting supports POST /users/{userId}/meetings Quick Meeting creation, and user:read:token supports user-level Meeting SDK token flows.

Server-To-Server Note

Some internal lab and customer-managed deployments may also use a separate Zoom Server-to-Server OAuth app for unattended customer-owned host workflows or legacy Quick Meeting creation. Only enable the scopes that match active features: user:read:token:admin for token relay, meeting:write:meeting:admin for Quick Meeting creation, user:read:user:admin for account user identity lookup, and meeting:read:meeting:admin for meeting lookup/validation.

Test Setup

Test Prerequisites

Internal Pixelogy operators also complete the native render-node Zoom runtime release checklist before presenting a render-node Zoom workflow for review or production. That checklist covers the SDKERR_MODULE_LOAD_FAILED(4) stale-helper fix, OTA packaging, canary deployment, and real-call validation.

  1. Pixelogy Control is reachable at the private review URL.
  2. At least one render node is registered and shown as available.
  3. The review browser can sign in to Zoom.
  4. If testing live Zoom video, the meeting host can approve any required host, cohost, or local recording permission prompts.

Test Cases

Test A — App Authorization

  1. Open the Pixelogy Control review URL.
  2. Sign in using the private Pixelogy Control reviewer credentials.
  3. Open the Zoom view from the Pixelogy navigation.
  4. In the Zoom account panel, confirm the app shows either a configured Zoom OAuth app with a Log in button, or a connected token/account state for the selected node.
  5. If the setup form is shown, enter the privately supplied Zoom OAuth client ID and client secret, then save the OAuth app configuration.
  6. Confirm the redirect URL shown by Pixelogy matches https://www.pixelogy.tech/zoom/redirect.
  7. Click Log in or Switch.
  8. Sign in to Zoom when prompted.
  9. Review the requested scopes.
  10. Approve the app authorization.
  11. Confirm the browser returns to Pixelogy Control.
  12. Confirm the Zoom account panel shows a connected state. In token-only mode, it may not show the Zoom email/display name because /users/me is intentionally disabled.

Expected result

  • OAuth succeeds.
  • Pixelogy shows the connected Zoom state. In token-only mode, this may be a generic connected state rather than verified Zoom profile identity.
  • Pixelogy stores OAuth tokens only for the authorized integration.

Test B — Create A Quick Meeting

Run this test only when the app has a meeting-write scope enabled. In token-only admin-managed mode, skip this test and use Test C.

  1. Stay in the Zoom view.
  2. In the node filter, select the review render node.
  3. Confirm the display name field is set, for example Pixelogy Node.
  4. Click Quick Meeting.
  5. Confirm Pixelogy displays the created meeting ID and passcode.
  6. If a Start Host link is displayed, open it in a separate tab or Zoom client to join as the meeting host.
  7. Confirm the selected Pixelogy render node is requested to join the meeting.
  8. In the Zoom meeting participant list, confirm the render node joins as a visible participant using the configured display name.

Expected result

  • A Zoom meeting is created for the authorized or configured host account.
  • The render node joins visibly; it is not hidden.
  • Meeting access follows Zoom host and meeting settings.

Test C — Join An Existing Meeting

  1. Create or open a Zoom meeting that the reviewer controls.
  2. In Pixelogy Control, open the Zoom view.
  3. Select the review render node.
  4. Enter the meeting ID or full Zoom join URL.
  5. Enter the passcode if required.
  6. Confirm the display name field, for example Pixelogy Node.
  7. Click Join.
  8. Confirm the render node appears in the Zoom meeting participant list.
  9. If the node needs cohost or local recording permission for raw video access, grant the requested permission from the Zoom host account.
  10. Click Refresh in Pixelogy Control.

Expected result

  • Pixelogy sends a join request to the selected render node.
  • The render node joins as a normal visible Zoom participant.
  • Host/cohost permissions remain controlled by Zoom.

Test D — Participant Display Workflow

  1. With the node joined to a meeting, return to the Zoom view.
  2. Confirm Pixelogy lists available meeting participants as cards.
  3. Use the participant search field to filter the participant list.
  4. Click a participant card to open the participant preview panel.
  5. Drag a participant card into the Pixelogy editor canvas or Zoom source area.
  6. Confirm the created surface uses a zoom://meetingId/participantId source.
  7. Save or push the project to the review render node if the review environment is configured for live output.
  8. Confirm the display output shows the selected Zoom participant video when host permissions allow it.

Expected result

  • End users can map Zoom participants to display surfaces.
  • Pixelogy renders live meeting video only for authorized, visible meeting participation.

Test E — Zoom Controls Exposed To End Users

Reviewers should exercise each visible control in the Zoom workflow. Each control below has a one-line description of its effect.

  1. Refresh reloads node and participant status.
  2. Node filter selects the render node to control.
  3. Log in / Switch starts Zoom OAuth authorization.
  4. Log out disconnects the saved Zoom OAuth account from both the live platform and the selected node account cache.
  5. Quick Meeting, when enabled, creates a Zoom meeting and optionally asks the node to join. In token-only review mode, this control should be hidden or disabled.
  6. Copy ID copies the created meeting ID.
  7. Copy Passcode copies the created meeting passcode when present.
  8. Join Node asks the selected node to join the created meeting.
  9. Start Host opens the Zoom start URL when available.
  10. Join asks the selected node to join a provided meeting.
  11. Test starts the simulator-backed participant workflow for non-production UI verification.
  12. Leave asks the selected node to leave the meeting.
  13. Host requests host behavior for the node when allowed by the meeting.
  14. Cohost requests cohost behavior and local recording/raw video access when allowed by the meeting host.
  15. Search participants filters visible participant cards.
  16. Participant card click opens preview metadata.
  17. Participant card drag maps the participant to a Pixelogy surface.

Test F — Disconnect And Denial Cases

  1. Repeat the authorization flow and click Deny on Zoom's authorization screen.
  2. Confirm Pixelogy returns to the Zoom view with an authorization error state and no connected Zoom account.
  3. Authorize successfully.
  4. Click Log out in the live web portal.
  5. Confirm Pixelogy removes the connected Zoom state from the web UI.
  6. Open the local/on-prem Pixelogy Control Zoom view for the same node.
  7. Confirm the local UI also reports the Zoom account as disconnected.
  8. Authorize successfully again, then click Log out in local Pixelogy Control.
  9. Confirm the live web portal also reports the Zoom account as disconnected.
  10. Click Leave while a node is in a meeting.
  11. Confirm participant cards are cleared after the node leaves.

Expected result

  • Denied authorization does not create a connected account.
  • Logout disconnects future app access from both the live web platform and the local/node account cache.
  • Leaving a meeting clears node participant state.

Data Handling

Data Handling Notes For Reviewers

Pixelogy stores Zoom OAuth tokens only as needed to maintain the authorized connection.

Customer render nodes do not store Zoom OAuth refresh tokens by default.

Meeting identifiers, join details, and operational status may be processed when a user requests a meeting workflow.

Pixelogy does not store Zoom meeting audio or video by default.

Zoom meeting media is processed only for live customer-controlled display output.

Operational logs are used for support, security, and reliability.