How to Get Your App Published to the Zoom App Marketplace on Your First Review!

We are using quality to differentiate the Zoom App Marketplace from all other app marketplaces. Our focus is “Quality over quantity for every app published to the Zoom App Marketplace”. Why, when it would be easier to pack as many apps in as possible as long as they met basic requirements?

Zoom customers expect apps on our Marketplace to provide the same standard-of-quality, and world-class user-experience they have come to expect from every Zoom product/service they use on a daily basis.

This blog post is all about how to get your app in-shape, and ready for a successful review, so you have the best chances of being approved to be published on the Zoom App Marketplace…on your very first review!

NOTE: Not every app will be approved on the first submission for review, our goal here is to not waste any more cycles than necessary and provide you with more insight into our review procedures and criteria.

Are there different types of App Review Requests?

Yes. Currently, there are four (4) different app review request types Zoom Developers can submit:

1. CREATE — First time apps that have never before been published.
2. UPDATE — New changes to apps that are already published
3. UNPUBLISH — Removes apps from the marketplace that are published, disconnects existing subscribers
4. REMOVE — Completely deletes apps and all data, disconnects existing subscribers

Here is a Gist that provides a little greater visibility into the different app request types and the result of them being approved. We are working on providing some additional request types, so keep an eye on the recent updates in our developer documentation for when these are released.

How Are App Review Requests Handled and How Long Does the Process Normally Take to Complete?

This is probably the most common question new Zoom Developers ask. You likely want to know: how long the process typically requires to complete, when requests are processed, how review requests are handled, and what you can expect from this process.

• Requests are processed 9am — 5pm (Pacific Time), Monday through Friday. (excluding major US Holidays)
• CREATE (new app) Requests are queued, and processed FIFO. It is expected that the “PRODUCTION” environment is operational for testing and that we have been provided with the username/password for a pre-provisioned test account in this environment.
• UPDATE (changed app) Requests are also queued, and processed FIFO. It is expected that the “DEVELOPMENT” environment is operational for testing, and that we have been provided with the username/password for a pre-provisioned test account in this environment. In order to test the new webhook and scope changes included in the update request, we need to authorize the development version of the app.
  NOTE: This is NOT your local workstation, please do not use the loopback IP (127.0.0.1 or localhost) for your callback URL, as we will automatically reject the request and ask you to provide a valid web-accessible URL (and any credentials needed to access this environment).
• UNPUBLISH and REMOVE Request types have serious business, customer, and legal ramifications which must be considered. Please review the terms within the Zoom Marketplace Developer Agreement for complete details.
• App Metadata is reviewed first. This is the content about your app that you supply while defining it within the Zoom App Marketplace, such as: Short Description, Long Description, Images, Resource URLs, Event (webhook) Subscriptions, Scope usage descriptions, and so on.
• Functional and Usability Testing. After your app’s metadata has been reviewed successfully, the app undergoes a complete set of functional and customer experience tests. We will follow the test plan you provide in the release notes for step-by-step instructions for how we can trigger each scope requested by your app
• How long does it take to complete an app review? Testing time varies per app based on app quality, app usability, quantity of features, and app metadata quality. For well-scoped apps with perfect metadata, it can be reviewed in a single day. Conversely, apps with lots of features, poor usability, or sub-standard metadata content can take much longer to complete.
• BEST PRACTICE: Focus on the single most valuable use case for your customers. This choice can help greatly reduce overall review length as well as the likelihood rejection-causing issues will be discovered (by us or you). Apps that try to do too much on their CREATE requests can easily overlook usability, user-friendliness, customer experience, and introduce metadata, content, functional, or usability issues. We also want to emphasize the importance of reviewing the quality and thoroughness of your app submission before submitting your request.

Zoom App Review Process at a High-Level

What are the Top 10 Reasons Apps Are Rejected?

App metadata (the information you provide in the Zoom App Marketplace while defining your app and all of its supporting content) is the lion’s share of all rejection cases to date.

1. Test Plan or Test Account not provided
   Please provide a test plan with a step-by-step guide on how to configure and use each scope requested in the integration. This should not be a user manual for your service as a whole, but instead a Zoom-specific document we can use to quickly test the use cases of the scopes requested. You should add a link to this document in the release notes of each submission.
   Please provide test credentials to your service so that we can test the full scope of this integration. If possible, an account that has existing/dummy data is best so that we can easily and quickly test and process your submission. As we are the last test before your integration goes public on our Marketplace, we will need to install the production version of your app into our own Zoom account, the same way an end user would. This way we can see the same experience an end user will have when they install your app.
2. Missing or Non-Actionable Documentation URL Content.
   Documentation URL content is one of the most critical pieces of information and also one of the most overlooked. Zoom’s Best Practice Recommendations for Organizing Your App’s Support URL Content.
3. Missing or Inoperative Deauthorization URL
   Every app must include a deauthorization_url for each app to be published on the Marketplace. This app must be able to accept and properly process Deauthorization Webhook events/data. Your app is expected to adhere to the Marketplace Developer Agreement as it relates to data-retention policies.
4. Using Long-Polling Instead of Subscribing to Webhook Events
   If your app is not subscribing to receive webhook event requests from Zoom, then you are long-polling our API (which we consider an anti-pattern). There are multiple reasons and benefits why developers need to subscribe to webhook events, the biggest being performance and monitoring. You can enable Webhook Subscriptions for your app in the “Features” section while building your app in the Zoom App Marketplace.
5. Assigning Unused or Over-Reaching Scopes
   The scopes developers set on their apps expose functionality and access to our APIs. Zoom expects developers to ONLY enable scopes which make functional, logical, and business sense for their apps. If we see that your app is NOT using API requests for a given scope, we will reject your app. The best advice is to only enable the minimum number of scopes in order for your app to operate at 100%.
6. Not Caching access_token or not using Refresh Token Flow
   If your app is making a request to /oauth/token before every other API request, we are going to reject it. Zoom’s access_token is valid for 1 Hour, and every 200-level response you receive from /oauth/token will include a refresh_token. Cache the data returned on responses from Zoom’s Auth endpoints, and re-use the access_token until it expires, then make a refresh token request to get a new token. If you are confused, read the docs on OAuth with Zoom.
7. Incomplete or Uninformative App Descriptions
   There are two app descriptions available for developers, the Short Description, and Long Description. The Long Description is usually the culprit. Because it does not provide Zoom Customers (whom are learning about your app to make an informed installation decision) with enough insight and information about what the app actually does.
   Each field has a distinct purpose:
   Short Description (text-only) — Info about your business’ core purpose for customers, 1–2 sentences. Think “what do we do” in a nutshell.
   Long Description (supports markup) — Detailed information about the business value your app provides Zoom customers, primary use cases, specific features, any requirements/prerequisites for users considering installing your app, and links/information to additional details and resources customers will need to know about: pricing/plans, Q&A, Chat with an Agent, etc…
8. Inoperative or Sub-Standard Installation Experience
   Zoom expects you to allow customers who want to install your app to be able to do this quickly, easily, and in a self-serve manner. There are two methods for installation, From Marketplace and From Landing Page URL. From Marketplace authorizes the app directly from your marketplace listing page and is intended for freemium or self serve systems. From Landing Page URL allows you to redirect the user to your site before authorization, allowing for any additional onboarding or login steps required before enabling the Zoom integration in their account.
9. App does not function as described, or lacks customer value.
   Before you begin developing an app for the Zoom App Marketplace, think about why. Here are some good indicator questions…
   1. Do you have customers who also use Zoom?
   2. Have you engaged these customers and asked what type of features on an app would really add value for them and make their lives better?
   3. Are you receiving several customer requests for an integration with Zoom regularly?
10. Technical Design Document not submitted
    After the functional test of your app, it will move to the Security Review. The Technical Design Document (or TDD) is the first step in completing the Security Review. Ensuring you email a detailed and thorough Technical Design Document to marketplace.security@zoom.us helps us to move your app to the next stage with ease.
    Additional details on our security review process can be found here:
    If you have any questions please feel free to reach out to our Security Review team at marketplace.security@zoom.us.

The first step towards a one-review-approval for the Zoom App Marketplace is making sure you’ve addressed these top 10 rejection issues.

Functional and Usability Testing

Next, make certain you app is functions without issues, errors, or technical/business hurdles. Then focus on well-executed app usability and that it performs consistently as customers would expect!

1. Is your app easy to install, and uninstall?
2. Do you either create new user accounts or allow new customers to your service to sign up for free accounts when installing your app from the Zoom App Marketplace?
3. Is your app easy to configure?
4. Do all the features of the app operate flawlessly and as described in your long-description?
5. Is your app easy to use (like…is it zombie-simple and super-intuitive)?
6. Does your app make it easy for customers to quickly find and receive support, help, or answers to their questions? Use this document to help organize your app’s Support URL for optimal customer support
7. Have you tested your app from installation-to-deauthorization, and properly covered every test case? Is the experience always 100% pleasant and satisfying for everyone who uses the app?

Consistently test your app (and all supporting app metadata) as a customer who knows nothing about how it operates or is used. Doing this, in addition to finding customers willing to beta-test your app, is a great way to quickly identify and resolve customer experience blockers, and to greatly increase the likelihood of your app’s approval.

Here are a couple of apps on the Zoom App Marketplace which I would consider a rubric for success: Acuity Scheduling and ThetaLake. These apps went through a few revisions, but the end-result is all the right information that customers need to make installation decisions is present.

In closing, the metadata you provide for your app while defining it in the Zoom App Marketplace is more than just form fields required to submit your Zoom app for review. Your app’s metadata, use cases, features, and user-friendliness define the quality our mutual customers will experience. Hopefully the information I’ve provided here will help you create amazing experiences for every customer! Your feedback is welcome in the comments to this post.