Google Workspace Marketplace App Review: The Gate After OAuth Verification
Passing Google OAuth verification does not put an app on the Google Workspace Marketplace. It clears one gate. A second, separate review — run by a different team, against a different checklist — still has to approve the listing before anyone outside the developer's own organization can install it.
Gate 1 — OAuth Verification
Checks whether the consent screen accurately represents the app and whether its use of sensitive or restricted scopes is justified. Required only when an app requests scopes beyond the non-sensitive tier. See the full Google Workspace API verification guide for that process end to end.
Gate 2 — Marketplace App Review
Checks the store listing content, branding, functionality, and user experience against the Marketplace program policies. Required for every public app listing, regardless of which scopes it uses.
Public vs Private
Private apps publish immediately with no Marketplace review — visible only inside the developer's own Workspace organization. Public apps require both gates. Google states the public/private choice cannot be changed once made.
Review Duration
Google states review "typically takes several days" and depends on submission volume and how much rework the app needs. No fixed SLA is published for Marketplace app review — see the OAuth verification timeline breakdown for how the separate OAuth clock works.
What the Marketplace Review Checklist Actually Covers
| Category | What reviewers check |
|---|---|
| App name | No duplicate listing name, no impersonation, no version number in the name, name matches the OAuth consent screen exactly, not vague or generic, 50 characters or less |
| Developer info | Developer name and website accurately represent who is behind the app; EEA users must be told whether the developer is a "trader" or "non-trader" under consumer protection law |
| App description | Every link works and points to the correct page; short and detailed descriptions must not be identical; third-party service interactions must be disclosed |
| Functionality | No obvious bugs, demonstrates clear interaction with Google APIs, offers functionality not already equivalent to an existing Google product, fully functional rather than a work in progress, a test account provided if paid features are gated |
| User experience | One-click or zero-click sign-in, no re-prompting for scope permission once a domain admin has granted it, working sign-out that revokes tokens, no Google brand assets in the app's own name or logo |
| Graphics | Icons sized and colored per spec, screenshots that are not blurry or inaccurate, nothing that mimics another brand's visual identity |
| OAuth | App has passed OAuth verification, uses the narrowest scopes possible, and every scope integrates correctly with the Google Services APIs it claims to use |
Chat apps, Drive apps, Editor add-ons, Workspace add-ons, and Web apps each carry additional integration-specific criteria on top of this base table. Two examples Google documents directly: a Drive app using restricted scopes must also pass a separate security assessment, and a Chat app must send an unprompted welcome message every time it is added to a space.
The Publish Flow, Gate by Gate
Create the Cloud project and configure OAuth
Fill out the OAuth consent screen, select the narrowest scopes, and create the OAuth 2.0 credential. If any scope is sensitive or restricted, submit for OAuth verification here — it can run in parallel with the steps below.
Test against the review criteria before submitting
Broken links and re-prompted sign-ins are named, documented rejection reasons, not edge cases — test the app against the same checklist reviewers use before touching the Marketplace SDK.
Enable the Marketplace SDK and declare integrations
Declare which Google Workspace applications the app extends. Adding an integration type later, after the listing is already live, triggers a fresh manual review on its own.
Build the store listing
App details, graphic assets (icons, a 220×140 card banner, at least one screenshot), and three required support links — terms of service, privacy policy, and support — are all mandatory before submission, public or private.
Submit for review
Private listings publish immediately. Public listings enter "in review" and cannot be edited until a decision comes back — approved and auto-published, or returned with a review document naming what to fix.
Documented rejection reasons, by category
- OAuth: consent screen still set to Internal user type, or publishing status still Testing, or OAuth verification simply left incomplete
- Listing: Google trademarks misused in the app name or logo, a link that points to the wrong page (Google's own example: a privacy-policy link that points to a support page instead), low-quality or inaccurate screenshots
- Readiness: the app is still being tested, has bugs, or is not fully functional — not a finished product yet
What forces a fresh review after launch
Only two actions trigger a new manual review on an already-published public listing: checking a new box in App Integrations, or editing anything in App Details — language, app name, short description, or detailed description. Other configuration changes can be saved and published as a draft without review.
The program policy most builders skip
Google does not allow ads to be served inside any product that integrates with Google Workspace — not just intrusive ads, all ads. The listing must also be business-related, support OAuth2, and never re-prompt a user for authorization once a domain admin has granted the requested scopes.
What Google does not publish — do not assume these
- No fixed review turnaround time or SLA — only "typically several days," explicitly tied to submission backlog and how much rework is needed
- No published approval or rejection rate for Marketplace app review
- No published limit on how many times a rejected listing can be resubmitted
- No complete list of what counts as a "Core Google Workspace Service" beyond Google's own reference page — not every Workspace-adjacent API automatically qualifies
Clearing both gates on the first submission means the store listing, the OAuth scopes, and the integration-specific criteria all have to be built to match the checklist before submission — not fixed one rejection at a time.