Connect

The connect section of a marketplace manifest JSON corresponds to the values on the Connect page in the app build flow.

It defines how your Zoom app authenticates with third-party applications, integrates external data, exposes REST APIs, registers incoming webhooks, and optionally provides an MCP server.

This document describes every field available in the connect section, including its data type, whether it is required, and any constraints enforced when the manifest is imported.

Note - Every field in the tables below is marked Required, Optional, or Conditional. Conditional means the field is required only in specific cases; the cases are stated in the field's own description.

Overview

A connector lets a third-party API be used as a set of building blocks inside the Zoom platform — for example, as actions and triggers in workflows, or as tools an agent can call. The connect object is where you declare that integration.

At a high level, the connect object answers four questions:

• How does the connector authenticate to your API? → the security block.
• What APIs can the connector call? → the routes array, where each route is one REST API on your service.
• Does your service need to send events to the connector? → the incoming_webhooks array.
• Does the connector need to call an MCP server? → the mcp block.

Manifest JSON

This is a display of the full connect schema populated with sample values.

You only include the sections your connector actually uses. A connector can be as small as a base URL plus authentication, or as rich as dozens of routes, webhooks, and an MCP server. Everything in the JSON is validated at import time; if any section is malformed, the import is rejected and you'll receive a validation error describing the problem.

{
    "connect": {
        "enable": true,
        "url": "https://api.example.com",
        "security": {
            "type": 36,
            "oauth_config": {
                "authorize_url": "https://app.example.com/oauth/authorize",
                "access_token_url": "https://app.example.com/oauth/token",
                "refresh_url": "https://app.example.com/oauth/token",
                "client_id": "abc123",
                "client_secret": "s3cr3t",
                "scope": "read write",
                "client_authentication": "header",
                "code_challenge_method": "S256"
            }
        },
        "routes": [
            {
                "name": "Get the current user",
                "path": "/users/me",
                "method": "GET",
                "key": "example_get_current_user",
                "description": "Returns the authenticated user.",
                "parameters": [
                    {
                        "name": "include",
                        "displayName": "Include",
                        "description": "Related resources to include.",
                        "in": "query",
                        "required": false,
                        "schema": { "type": "string" }
                    }
                ],
                "response": {
                    "description": "Current user",
                    "content": "application/json"
                }
            },
            {
                "name": "Create item",
                "path": "/items",
                "method": "POST",
                "key": "example_create_item",
                "request_body": {
                    "required": true,
                    "content": "application/json",
                    "schema": {
                        "type": "object",
                        "properties": [
                            {
                                "key": "title",
                                "name": "title",
                                "type": "string"
                            },
                            {
                                "key": "count",
                                "name": "count",
                                "type": "integer"
                            }
                        ]
                    }
                },
                "response": {
                    "description": "Created",
                    "content": "application/json"
                }
            }
        ],
        "incoming_webhooks": [
            {
                "name": "Item events",
                "short_description": "Fires on item changes.",
                "key": "example_item_events",
                "type": "RestHook",
                "status": "READY",
                "state": "ON",
                "authentication": {
                    "key": "X-Signature",
                    "secret": "whsec_xxx",
                    "algorithm": "HMAC_SHA256",
                    "encoding": "BASE64",
                    "prefix": "sha256="
                },
                "validation": {
                    "enabled": true,
                    "request_key": "challenge",
                    "response_key": "challenge"
                },
                "rest_hook": {
                    "subscribe": { "route_key": "example_create_item" },
                    "unsubscribe": { "route_key": "example_create_item" }
                }
            }
        ],
        "mcp": {
            "base_url": "https://mcp.example.com/sse",
            "name": "Example",
            "ext": {
                "description": "Example MCP server"
            }
        }
    }
}

Connect

The connect object sits inside the marketplace manifest and carries the following top-level fields.

Enabling connect

Whether the connect capability is active depends on enable and on whether you've actually provided any connect data. In practice, the minimum you need is to set enable: true and provide at least a url.

If you want to ship a manifest with the connector temporarily turned off, set enable: false — your other connect fields are preserved in the manifest but not activated.

The manifest tool will also consider connect as disabled and all connect data is ignored if enable is omitted and the connect object is effectively empty — that is, url is blank, security is null, routes is empty, and incoming_webhooks is empty.

Security

The security block tells the platform how to authenticate every request the connector makes to your API. You pick one authentication type, then supply the matching credential and endpoint fields inside oauth_config.

Validation notes

• If connect is enabled and the security block is malformed for the chosen type, the import is rejected with an authentication validation error.
• MCP overrides security.

When an mcp block is present, the MCP configuration takes precedence over the security block — regardless of whether an authentication type is set — and authentication is handled as part of the MCP configuration instead.

Type values

Each authentication type has a stable numeric code. The codes are not sequential; gaps are intentional (some values are reserved and are not part of the manifest import path). Use only the values listed here.

Notes for OAuth types

• Redirect URL is server-assigned. For Authorization Code (31) and Authorization Code + PKCE (36), the OAuth redirect URL is assigned by the platform when your manifest is imported. Do not set it in the manifest; register the assigned value with your identity provider after import.
• Token request delivery. On import, the OAuth token request is always sent with parameters in the request body. Any request_type value you supply is informational only and does not change this behavior.
• Client Credentials — (client_id / client_secret are optional) For OAuth2 Client Credentials (34), you may set client_id and client_secret in the manifest. If you do, they apply to every customer using the app. If you leave them out, each end user is prompted to provide their own when they install and connect the app.

oauth_config fields

These are the credential and endpoint fields referenced by the security type. Include only the fields that apply to your chosen type.

Write-only fields

Write-only fields (token, password, secret, client_secret) are accepted on import but are never returned when a manifest is exported. Treat them as sensitive: supply them once, and expect them to be redacted in any read-back of the manifest.

AWS SigV4 fields

Use these fields when authenticating to an AWS-hosted API with Signature Version 4. The role and region can be provided here as defaults and overridden per connection when a user sets up the connector.

Routes

Each entry in routes defines one REST API the connector can call — a single request against your connector's base url. Routes are what become usable inside the Zoom platform (for example, as steps in a workflow or as tools an agent can invoke). Define one route per meaningful operation your API exposes.

Note

• You can set up to a maximum of 100 routes.
• Every non-blank key must be unique across the array. The key is the identifier used to reference the route elsewhere (including from incoming webhooks); it is important to keep it stable across manifest versions.

Parameters that reference another route's output (cross-route dependencies) are validated after all routes have been parsed, so the referenced route can appear anywhere in the array.

Parameters

A parameter describes a single input to the route — a path segment, a query argument, or a header. Define one entry per input your API accepts so the platform can prompt for and pass the right values.

To describe the request body, use the request_body object, not a parameter.

Request_body

Describes the payload sent with the route, for methods such as POST, PUT, and PATCH. The request body is defined here as a single structured schema — it is not described through the parameters array.

Response

Describes the response your API returns for the route. Defining a response schema lets the platform map your API's output into downstream steps.

Schema

A recursive, JSON-Schema-like structure used to describe the shape of parameters, request bodies, and responses. Nest it to represent arrays and objects of any depth.

Setting up recursion:

For an array, describe the element type in items.

For an object, list its fields in properties, where each entry is itself a schema and can contain further items or properties.

Primitive types (string, integer, number, boolean) are leaf nodes.

Incoming webhooks

An incoming webhook lets your service push events to the Zoom platform rather than being polled. Each entry defines one webhook the connector registers.

There are two kinds of webhooks:

• RestHook — the platform subscribes and unsubscribes by calling routes you've defined (for example, "create subscription" / "delete subscription" endpoints on your API). Use this when your service supports dynamic subscription management.
• Static — a fixed webhook with no subscribe/unsubscribe lifecycle. Use this when events are delivered to a fixed endpoint.

Limits and uniqueness

• The number of incoming webhooks an app can define is capped by a per-app maximum (default 100).
• Every non-blank key must be unique.

Signing secret

A webhook typically reaches status: READY only once its signing secret is set. (See secret in authentication). Until then it may remain INCOMPLETE.

Authentication

Configures how the platform verifies that an incoming request genuinely came from your service, by checking a signature you attach to each delivery.

Validation

Configures the initial handshake some services perform to confirm a webhook endpoint before sending events (an echo/challenge exchange).

Rest_hook

rest_hook binds the webhook's subscribe and unsubscribe steps to routes you've defined and applies to RestHook webhooks only.

MCP

If your connector exposes a Model Context Protocol server, declare it here. This lets the connector surface your MCP tools on the platform.

EXT

Why ext is required but none of its listed fields are:

The complete manifest defines additional ext fields that are required internally but are managed by the platform and are not exposed to external developers. Because of those internal fields, the ext object itself must be present — but none of the externally-available fields listed above are required. Set description only if you need it.

Implementation rules:

• How the OAuth client ID is obtained

  For an MCP connector, Zoom obtains the OAuth client ID programmatically — it registers with your authorization server automatically, using either Dynamic Client Registration (DCR) or a Client ID Metadata Document (CIMD). The Zoom MCP client supports both. Because registration is handled programmatically, do not set a static client_id in security.oauth_config; if you supply one, it is rejected on import.

• If base_url fails validation, or the server is unsupported, or another server-side error occurs, the import is rejected with a corresponding validation error.

Constraints & limits