Zoom Marketplace Approval: Four Rejection Rounds Detail

Sponja's 20-day journey to Zoom Marketplace approval exposed critical integration pitfalls. Founders can learn from the specific technical and process challenges encountered across four rejection rounds.

Sponja, a post-event intelligence app for Zoom meetings, spent 20 days navigating the Zoom Marketplace approval process, enduring four distinct rejection rounds. Founder RoeeTsur detailed the specific technical and procedural hurdles, including a critical production bug identified by reviewers and a feature built solely for their access. This experience highlights the granular scrutiny applied by major platform marketplaces, even for integrations already functional for early customers.

Building a Reviewer Login

Sponja's initial setup relied exclusively on Google SSO, posing an immediate barrier for Zoom reviewers who needed direct login access. To circumvent this, Sponja developed a hidden, email-password login page, accessible only via a direct URL. A reviewer account was then manually created in Firebase Console, granting the Zoom team entry. This "hidden door" was deployed to production and remains part of Sponja's infrastructure, explicitly for marketplace reviews. The internal code review process approved it under a "do not touch" label, acknowledging its singular purpose [1].

Mapping Scopes by Endpoint

The second rejection round centered on scope declarations. Zoom's reviewers identified four scopes declared by Sponja that did not correspond to explicit API calls within the application: webinar:read:webinar, webinar:read:list_past_participants, cloud_recording:read:list_user_recordings, and cloud_recording:read:meeting_transcript. RoeeTsur noted a specific discrepancy with cloud_recording:read:meeting_transcript. While Sponja required transcripts, they were obtained via the recordings file list, which uses a different scope, not the GetMeetingTranscript endpoint gated by the flagged scope. Despite the reviewer's incorrect reasoning for the specific scope, the conclusion to remove it was accurate. This revealed a critical lesson: map required scopes by the specific API endpoints they gate, rather than by their descriptive names [1].

Diagnosing Environment Swaps

The third rejection round involved "Errors during testing," with reviewers providing screenshots of Sponja's API calls failing and test events stuck in an "ingesting" state. This indicated widespread 404 errors. The root cause was a swapped Zoom Client ID between development and production environments in Sponja's secrets manager. Production functions were attempting to verify webhook signatures using the development secret, leading to silent failures for every event. The fix required a two-character change, but identifying the problem took hours of debugging. The lesson was clear: when a marketplace reviewer sends you a screenshot of your own bug, do not yet trust your own assumptions about which environment is broken [1].

Addressing a Grab-Bag of Issues

The final rejection round encompassed a variety of issues. First, the listing lacked sufficient images, requiring additional screenshots. Second, localhost was present in Sponja's production OAuth redirect URIs, a common development oversight that needed removal for a live application. Third, Zoom reviewers flagged a "Vulnerable Library" due to a Next.js CVE published mid-review. This required a simple pnpm up command to update the dependency and resolve the security vulnerability. After these corrections, Sponja received approval [1].

WHAT WE'D CHANGE: The Sponja experience offers valuable tactical insights, but some approaches warrant modification for broader applicability or long-term sustainability. The "hidden door" login page, while effective for Zoom's immediate review, introduces technical debt and potential security risks. Maintaining an unlisted, manually managed login for a single external user creates an attack surface and a non-standard authentication flow. A more robust solution would involve implementing a dedicated review mode within the application that allows for temporary, auditable reviewer accounts with controlled access, or integrating with a more flexible SSO provider that Zoom could use for review.

The scope mapping challenge, while specific to Zoom's granular API design, highlights a universal problem in platform integrations: documentation often lags or is open to interpretation. Founders should proactively build a comprehensive internal mapping of required API calls to their exact scope requirements, ideally before submission. This involves rigorous testing against a staging environment that mirrors the marketplace's review setup. Relying on descriptive scope names without verifying the underlying API endpoints is a common pitfall.

The Client ID swap issue is less a Zoom-specific problem and more a fundamental DevOps and secrets management failure. Relying on manual verification for environment secrets introduces human error. Implementing automated environment validation checks as part of the CI/CD pipeline, ensuring correct secrets are loaded for each deployment target, would prevent such errors. Tools for secrets management should enforce strict separation between dev and prod credentials, making accidental swaps difficult. The Next.js CVE, while a timely catch by Zoom, underscores the necessity of continuous security scanning and dependency management. Integrating automated vulnerability scanning into the development workflow, rather than relying on external review, is a baseline requirement for any production application.

LANDING: Sponja's path to Zoom Marketplace approval illustrates that platform integration is not merely about functional code, but also about navigating stringent, often opaque, review processes. The lessons—from precise scope mapping and robust secrets management to proactive security hygiene and thoughtful reviewer access—extend beyond Zoom. Each rejection round represented a specific failure point, many of which are common across platform integrations. Founders building on third-party ecosystems must anticipate these challenges, treating marketplace submission as a distinct phase of product development requiring dedicated technical and procedural rigor. This approach minimizes delays and mitigates the risk of critical issues surfacing late in the deployment cycle.

Pull quote: “The lesson was clear: when a marketplace reviewer sends you a screenshot of your own bug, do not yet trust your own assumptions about which environment is broken.”