What it takes to get approved on the Zoom App Marketplace

I want to write this down while it's fresh. Almost nothing I found online prepared me for what the Zoom review team actually checks, and we just came through it the hard way.

Sponja is a post-event intelligence app for Zoom meetings and webinars. The integration was live for our early customers before we submitted to the marketplace, so I walked in thinking "we've been running this in prod for weeks, how bad can the review be." I was wrong about that.

If you're about to submit, or you're in the middle of a review cycle right now, this is what they actually care about.

Round 1: They need to be able to log in (so they can actually use your app)

The first rejection came back with the subject line "Account Credentials - CREATE."

What this means: the review team is going to log into your app and exercise the integration end to end. They need credentials. If your only auth method is "Sign in with Google" or any other federated SSO, they can't create an account on their own, and they will reject you.

Sponja was Google-SSO only at the time. I had to ship a second auth path. We added a separate email and password login flow specifically for the Zoom review team, with their account provisioned manually. It's normal Firebase auth on a dedicated route. The review team uses it.

If I had read this post before submitting, I would have built that flow upfront. It's the lowest-effort thing on this entire list and it removes a full round trip.

Round 2: They test every scope and remove the ones you don't use

This is the round that taught me the most. The reviewer sent this email back:

By following the test plan provided, we have validated the use of scopes and found:

webinar:read:webinar - No calls to fetch webinar details were found.

webinar:read:list_past_participants - No calls to list webinar participants were found.

cloud_recording:read:list_user_recordings - The developer lists recordings by Meeting ID, not by User ID.

cloud_recording:read:meeting_transcript - Although you receive a 'transcript ready' webhook, you never call the API to actually read or download that transcript.

Please remove these scopes at this time to pass the functional portion of this review. If you need these scopes, please expand on your test plan that includes steps to test for them.

Two things to know about this round.

The reviewer instruments every test call against your app and checks it against the scopes you requested. If a scope isn't exercised during their test, you either remove it or write a test plan step that forces them to hit it. There's no arguing. If you want to see how this maps to a real integration, we publish exactly what data Sponja reads from Zoom and what each scope is used for.

The test plan you submit is the whole game. They follow it literally. If your test plan only covers meeting ingestion and not webinar ingestion, you cannot keep the webinar scopes. The fix isn't to push back, it's to write a plan that walks them through every integration path you actually need.

The interesting one for us was cloud_recording:read:meeting_transcript. We had requested it because we ingest transcripts and the scope name says "meeting_transcript." But that scope actually gates a separate endpoint called GetMeetingTranscript, which we don't call. Transcripts come down through the recordings file listing under a different scope. We removed the scope and kept the transcripts. The takeaway: map scopes by endpoint, not by what the scope name sounds like. The granular scopes table at developers.zoom.us is the source of truth.

We expanded the test plan to cover webinars, dropped the unused scope, and resubmitted.

Round 3: When their tests fail, sometimes you really are the bug

The reviewer came back with two screenshots. One showed their Zoom developer dashboard with our API calls erroring out. The other showed our dashboard with their test events stuck in "ingesting" forever.

My first instinct was that their test events just didn't have cloud recording enabled. That would explain the 404s. It was the wrong instinct.

After spending an hour in Cloud Logs and Firestore for that specific team, we found the actual cause. We had recently rotated our Zoom credentials and the dev and prod Zoom Client IDs ended up in the wrong secret slots. Production was verifying webhook signatures against the dev secret. Every signature failed silently. Every event got stuck.

The blast radius was narrow (events that came in during a short window after the rotation), the fix was one secret update, and we added a release-time check so the active environment's secrets get verified before any deploy that touches webhook handling. The bug was real. The catch was also real. Zoom's review process is genuinely thorough.

The portable lesson is: before you hand the marketplace team your test plan, double-check that your dev and prod credentials are in the right slots. The cost of skipping this check is two days of confused back-and-forth with reviewers who can't figure out why your app is broken.

Round 4: The grab bag (you will get nitpicked)

By round 4 they were down to the listing-level stuff:

• Not enough images. The screenshots in our listing weren't enough. They want to see the actual experience, not just a single hero shot.
• "Redirect Localhost." We had localhost in our production OAuth redirect URI configuration. They flag it as a hardening issue. Remove all localhost and 127.0.0.1 entries from your production OAuth config before submitting.
• Some small listing copy fixes.

This round took 24 hours. It's the round where you should expect to be nitpicked and you should not push back. They're doing their job. Fix the things, resubmit, done.

What I'd tell a friend who's about to submit

A few concrete things.

Build the reviewer login path before you submit. Whatever your normal auth is, add a separate email and password login for the review team. Saves you a full round.

Write the test plan from the reviewer's perspective. The reviewer copy-pastes your steps and runs them literally. If you write "trigger a webinar ingestion," and there's no obvious way to do that in your app, they'll skip it and reject the scope. Spell out every click.

Match every requested scope to a specific API call in your test plan. Don't request scopes "just in case." For each scope, your test plan should have a step that causes that scope to be exercised. If you can't write that step, drop the scope. And look the scope up by the endpoint it gates, not by its name.

Audit your prod config before you give them the test plan. Verify dev and prod credentials are where they're supposed to be. Remove localhost from prod OAuth redirects. Make sure your webhook secret matches the right environment. The reviewer will trip on stuff you've been living with for weeks.

Expect 4 rounds, not 1. Plan two to three weeks end to end. The review team is responsive but each round has overhead. If your launch depends on being live by a specific date, start the submission a month out.

Why we did this

Sponja runs on top of Zoom. We use the attendee data to surface the buying-intent signal hiding in your webinar attendance reports, then turn each session into a per-attendee follow-up email grounded in what every person actually did. We can ingest that data through OAuth without being on the marketplace, but the listing is what makes us discoverable to the Zoom user base, what builds trust at the install moment, and what lets us grow beyond hand-shared signup links.

The 20 days were worth it.

If you're building anything on top of Zoom meetings and webinars, this is what we built. If you're in the middle of a marketplace review and any of this would have saved you a round, my DMs are open.