When selecting a name, make sure that you:
Create a distinct brand for your app. Choose a unique, simple, explanatory name (50 characters max) that highlights your app's functionality; alternatively, you can use your company or brand name.
App names and any related URLs should not include or consist of:
- The "Zoom" mark, any variation of the word "Zoom," or any other content that is similar to the name of one of Zoom's products or services; however, you can use "Zoom" in your name to demonstrate compatibility or integration with Zoom if needed (for example, Awezum App for Zoom). Your app must make it clear in all copy and designs that your integration/app is from a non-Zoom company.
- Content that indicates or implies Zoom endorses you or your app.
- Any content that attempts (or appears to attempt) to impersonate another person, account, or entity.
- Generic terms or names that can be confused with an existing company or app.
- The word "official" unless sanctioned by the person, place, or organization with whom the connection is asserted.
- Content that is illegal or that violates another person's or entity's rights, including intellectual property rights and privacy rights.
Zoom reserves the right to remove or require a revision to any content, in whole or part, including an app name, that violates these Requirements, the Marketplace Developer Agreement, the Zoom Terms of Service, our Community Standards, or for any other reason at our sole discretion.
There are two descriptions available for developers, the Short Description and Long Description, each with a distinct purpose:
Use the Short Description to provide information about your business's core purpose for customers and summarize what your app does. Highlight features or typical use cases of your app. Short descriptions should be one to two sentences (up to a maximum of 150 characters), and can be updated when submitting new versions.
Provide a Long Description that highlights the features of your app. Use this section to describe your App as a service, and your company as an organization. This is your opportunity to tell Zoom users why they should add this integration, what value does your app provide, and why your app is the right solution for them. Ideal descriptions contain a concise, informative paragraph followed by a short list of main features.
Long Descriptions can commonly cause an app submission to be denied if it lacks sufficient information about app functionality. Long Descriptions can be updated when a new version of the app is submitted.
Images are required to show users what to expect when using the submitted app, including function and user interface examples. Videos (up to 40 megabytes) provide expected app usage and user interface interaction.
For an example of high-quality image and video content, refer to the Hubspot app on the Zoom Marketplace.
If your app tracks user activity, you must provide examples of the activities that are tracked and the information that is collected from the activity. If your app provides a way for users to manage and control the permissions that have been granted, you must list out the steps that users can follow to do so.
Description of Service and Usage Limitation — Include brief information on the services that your app provides to the users. If any of the services are to be used only for personal needs and not commercial usage, include this information in the ToU. If there are specific practices that you want the users to avoid while using your app, clearly state them in the ToU.
Description of Expected Procedures and Liability — If your app has certain maintenance windows during which the guaranteed uptime can deflect, include this information on the ToU. In cases of data and business loss of your app users, state who is liable to mitigate for the loss.
Although you can refer to these instructions for getting started with writing your ToU, it should not be treated as an exhaustive list. Consult with your company's legal team to get support authoring a ToU that best meets your app and business requirements.
All published apps are required to provide a Support URL that provides information to users about how they can access on-going support for your app. The expectation is that users must have a clear communication channel and that support is provided within a reasonable timeframe in alignment with industry best standards.
The support page must include:
- The support team's hours of operation.
- First Response SLA. This is the maximum amount of time that a customer should expect to wait until they receive their first response from a member in your Customer Support team.
And any combination of the following support options:
- Link to create a support case.
- Link to email support.
- Link to your knowledge base or forums.
- Link to a live customer support channel (if available).
- Support's phone number (if available).
By providing this information, your app is better-positioned to serve our mutual customers and create a positive experience when they seek support for your app.
All published apps are required to provide a Documentation URL to guide users through adding the app and usage. When creating documentation, provide the following guidelines:
Adding the App — Required. A step-by-step guide for a user to add your app. Link to a troubleshooting guide.
Usage — Required. For each feature or action, provide a clear use-case description and a list of any prerequisites.
Removing the App — Required. A guide to removing the app from your Zoom account. Notify the user the implications of removing the app, and how you remove their data. If your app has specific requirements, be sure to include these. A simple list will suffice, as removing and de-autghorizing is handled by Zoom.
In the following example list, "XYZ" refers to your app. Replace "XYZ" with your app's name:
- Login to your Zoom Account and navigate to the Zoom App Marketplace.
- Click Manage >> Added Apps or search for the "XYZ" app.
- Click the "XYZ" app.
- Click Remove.
Troubleshooting — Optional, but highly recommended. List the most common user issues and their solutions including issues adding the app, adding meetings, accessing recordings, etc.
FAQ — Optional. List the most frequently asked questions, including questions on authorization, activation emails, or unsubscribing to email updates.
Contact Support — Optional. Describe what users can expect when engaging your support team including the hours of your support team and first response SLA (maximum time a user should expect to wait to hear from your support team). Provide a link to create a support case or contact support through email, Knowledge Base, forums, or phone.
All apps must provide the proper ability for a user to remove or deauthorize your app in compliance with Zoom's commitment to security and the protection of user data. To do so, apps must provide a secure endpoint for receiving Deauthorization notifications from Zoom. For more information, read our Deauthorization documentation.
Apps are expected to adhere to optimal patterns of requesting and subscribing to data from Zoom. Long-polling the Zoom API instead of subscribing to receive Webhook event requests is considered an anti-pattern and may cause the app to be denied. There are multiple benefits to subscribe to Webhook events, the most significant being performance and monitoring. Enable Event Subscriptions for an app in the Features section while creating or managing the app on the App Dashboard.
Scopes added to apps expose functionality and access to Zoom APIs. To help ensure the App only has access to the APIs necessary for the App's functioning, Zoom expects all developers to only enable Scopes to make functional, logical, and business sense for their apps.
Apps should not make overly frequent requests for OAuth tokens. A token should be requested and stored to allow an app to make API requests, rather than generated on each request.
Data returned on responses from Zoom Authentication endpoints should be cached and
access_tokens should be re-used until expired. Once expired, a Refresh Token request can be sent for a new token. For more information on this flow, read our OAuth with Zoom documentation.
In the Add allow lists text box, include all unique URLs that Zoom should allow as valid Redirect URLs for your OAuth flows. This additional security measure ensures that users are only redirected to the pre-approved endpoints that you provided in this field. Make sure to include either the complete URL (
https://subdomain.domain.tld/path/to/oauth/callback) or the base URL, omitting the path and/or query parameters (
This is a required step to secure your app and prevent unwanted tampering when adding your app. To minimize the risk of sensitive data leakage, only include URLs that you have provided in the Redirect URL for OAuth field.
Prior to your app submission, ensure that you are following the guidelines listed below regarding your URLs:
- Secure your URLs with HTTPS.
- Use fully-qualified domain names (FQDN) and refrain from using any
- Refrain from using ngrok domains. If used, you will be required to provide proof of ownership of the specific ngrok domain.
- Refrain from using any default Heroku app domains, such as
app_name.herokuapp.com. Instead, use custom domains. When using domains that are different from your app's domain, you will be required to provide a justification for the addition of these to the allow list.
Select an option to enable users to add your app:
- From marketplace
Displays an Add button on your app listing page. Users click Add and then Authorize to proceed to the redirect URL you specified.
From your landing page
You specify a landing page URL for your app. Users click Visit Site to Add on your app listing page and are redirected to your landing page for authorizations.
Use this option to restrict authorization of your app to only users who already have an account within your company. This is particularly effective if your app requires users to enter unique or organization-specific subdomains to log in to your app (example:
Your landing page must provide:
Logged-in users a means to authorize the integration.
Unauthenticated users a means to a authenticate themselves and then authorize the integration.
Best practice for Landing Page URLs is to use a deep-linked URL that is behind a paywall or login system (so your system can identify the user by requiring them to first authenticate). On successful authentication, the user is redirected to your deep-linked landing page URL (example:
For vendor attestation, download the Technical Design Document (TDD) and answer all questions.
In the Application Development section, for any questions answered as Yes, you must provide supporting evidence documentation.
In addition to the TDD, you must provide documentation to support your app's security attestations. The information is confidential and used only to complete the App Security Review.
Security evidence documentation is required for these app review requests:
- Request to publish Zoom Apps apps
- Request to publish SDK + OAuth apps
- Request to share private apps (all types)
Examples of evidence documentations:
- Evidence of SSDLC.
- Evidence of enforcing secure coding practice based on industry standards like OWASP.
- Evidence of SAST (Static Application Security Test) and/or DAST (Dynamic Application Security Test).
- Evidence of 3rd Party Application penetration testing.
- Privacy and security policy.
- Vulnerability management policy or procedure.
- Infrastructure/dependency management policy or procedure for patching systems and updating dependencies.
- Incident management process or procedure
You can contact the Marketplace Security Team with any questions about the TDD. email@example.com
In addition to following the steps listed above, ensure that the contents that you submit for publication such as app descriptions, support documentation, images and video files, do not expose your App Credentials and other private information. Blur all mentions of information such as tokens, passwords, and keys to secure confidential data.
Want to ensure that your app is ready for submission? Fill out this form prior to submitting your app so that you can assess your app in its current state. Once you complete the assessment, you will receive an email with a link to an auto-generated App Review Report highlighting existing issues and recommendations on how to resolve those issues.