How long does Zoom's app review take, and what does it ask for?

Why an app that creates Zoom meetings needs the review

To create a Zoom meeting on someone's behalf, your app needs that person to authorize it with Zoom OAuth. Zoom's rule for who can authorize an app depends on the app's type. In Zoom's words, "Public and unlisted apps undergo a dedicated review process," and "Private and beta apps do not require review." The catch is what the unreviewed types allow:

• Private. "Access is restricted to only users on your Zoom account." Fine for an internal tool, useless for a product.
• In development. Zoom allows "beta app access only to members of the developer's Zoom account."
• Beta, shared by link. You can share an authorization URL outside your account, but "you must get approval from Zoom" first. The link lasts 4 weeks, with two more 4-week extensions on request, and Zoom's FAQ caps it at 10 installs for an account-level app and 100 for a user-level app. While it is active, you may not make "any information about your app public."

Unlisted does not get you out of it. An unlisted app is hidden from the Marketplace but "can still be installed by anyone who has the direct installation link," and it goes through the same review. As a Zoom staff member put it on the developer forum, "If you want your app to make api calls on behalf of third party users you would have to submit your app for review with our marketplace."

What Zoom asks for

A submission is a full Marketplace listing plus documents for the reviewers.

1. Four URLs on your own domain. Support, documentation, terms of use and privacy policy, all "hosted on fully qualified domain names (FQDNs) owned by your company." Google Drive or Dropbox links are refused. The company name in the privacy policy and terms must match the app's company name, and the privacy policy must tell users their data subject rights and how to use them.
2. Domain verification for those URLs and your OAuth redirect and webhook URLs, by TXT record, HTML file or meta tag.
3. User documentation with three sections: adding the app, using it, and removing it, including "how user data is handled after removal."
4. A listing. Two to three images at 1200 x 780 px, a short description of at most 150 characters, a long description and a support page with hours and a first-response time.
5. A test plan, "required for each submission, including re-submissions," with "login credentials for two different accounts" so the reviewers can try your app.
6. A reason for every scope. "Developers must provide justification and detailed testing instructions for each requested scope." A scope your app requests but does not use is a rejection.
7. The Technical Design section. Your programming languages and frameworks, your "third-party libraries, SDKs, and dependencies (with versions, if possible)," the APIs and infrastructure you use, and an architecture diagram of "all services and components that interact with Zoom."
8. Removal handled properly. Your app listens for Zoom's deauthorization event and revokes the token.
9. Company details. A free Zoom developer account has to add a credit card. To be listed in the EU you give Zoom your business address, phone and email.

The security review

Every app gets one. Zoom tests apps "against the OWASP Top 10 risks," with "verification of least-privilege access," web application security scanning, manual testing for misuse, and "checks for vulnerable libraries." Zoom's security requirements also ask for:

• Encryption in transit, at TLS 1.2 or higher, and at rest.
• Static and dynamic security testing, and open-source component analysis.
• Logging you can investigate from.
• HTTPS everywhere, with no localhost, ngrok or default Heroku addresses in the app's URLs.

Zoom also rejects patterns that work fine in development. A staff member on the forum: "If your app is making a request to /oauth/token before every other API request, we are going to reject it." Long-polling the Zoom API is out too.

How long it takes, according to Zoom

Zoom's docs do not give a time for a first submission: "An app's review time varies based on app quality, usability, quantity and function of features, and clarity of information." What Zoom's staff have said on the developer forum:

Zoom checks the submission's documents before security testing begins, and every round of changes adds to the total.

How long it takes in practice

The forum has reports well past those numbers:

• Over 10 weeks with no first response, for a scheduling app, in 2026.
• Eight weeks against the six the testing notes stated, in 2022.
• About three months in security review before approval, in 2025.

These are self-reported, so read them as a pattern. One thing makes waits longer: while your submission is in the queue, you cannot change the app. Zoom staff: "App changes can only be made when the app is not in the review queue. You can either withdraw the current submission to apply updates or wait for approval."

Where submissions get sent back

Zoom publishes its list of common rejection reasons. The ones that catch most teams:

• A test plan without enough detail, or the wrong client ID in it.
• Support, documentation or policy pages on a domain your company does not own.
• User documentation that does not cover adding, using and removing the app.
• Listing images or descriptions that miss the requirements.
• Scopes the app requests but does not use.
• A removal flow that does not handle deauthorization.

After a rejection, Zoom sends a report with action items. "You must review all notes from the Review Team and respond to or acknowledge them before resubmitting your app," and the resubmission needs a test plan again.

Every new scope goes back through review

Passing once does not finish it. "Changes to scope, features, or data access need to go through both a functional review and a security review," and Zoom's docs say this "may take up to 5 business days." You write a test plan for each new scope. Existing users keep their old authorization for 90 days, then have to authorize again. So adding, say, webinar support to a published app is another review, and another reconnect for every user.

Or skip it

If your users connect Zoom through a service whose Zoom app Zoom has already approved, the review is that service's work, not yours. That is how Pyas works on every plan, the free one included. Hosts approve Pyas's Zoom app on Zoom's own consent screen, and you ask for a Zoom link on any Google Calendar or Outlook event with one field. Pyas creates the meeting on the host's own Zoom account, so Zoom's limit of 100 meeting creates and updates per user per day is each host's, not your whole app's.

When you want your own name on Zoom's consent screen, switch Zoom to Native Auth with your own Zoom app, and go through the review on your own schedule while your users keep working.

Common questions

Can I launch while the review is pending?

Only through a beta authorization URL that Zoom approves, and only for a few weeks at a time, within the install caps above, and without telling anyone publicly that you have a Zoom integration. Once the link expires, "new users are not allowed to add your app."

Does an unlisted app skip the review?

No. Unlisted only hides the app from the Marketplace. It is reviewed the same way and still needs the listing details.

Does a calendar API handle Zoom's review for me?

It depends on the API. Nylas's docs say "You create a Zoom OAuth app, connect it to Nylas as a conferencing connector," and that "If you need users from multiple domains, you must go through the Zoom app review process." With Pyas Auth, your users approve Pyas's Zoom app, so there is no review of your own. See Pyas vs. Nylas.

Do I need a paid Zoom account to submit?

A free developer account can submit after adding a credit card to it, or by sending Zoom a form.