Google Workspace API Verification: Why the Approval Path Is Different
You fixed the “This app isn’t verified” warning. You passed Google OAuth verification. Your app still gets blocked when it reaches Workspace customers — because Workspace API approval runs on a completely different track from standard consumer OAuth.
Two Tracks. One API Console. Completely Different Gates.
Consumer OAuth Path
For apps that access individual Google Accounts (@gmail.com users). Covered in the Google OAuth verification guide. Requires brand verification plus sensitive and restricted scope review. Shows the “app isn’t verified” warning screen to users until verification passes.
Google Workspace API Path
For apps accessing Workspace-managed accounts in organizations using Google Workspace. Requires everything in the consumer path PLUS: domain-wide delegation authorization by a super-admin, a separate Workspace Marketplace review if distributing, and API access control approval inside each target org’s Admin Console.
4 Scenarios Where You Are in Workspace Territory
Admin SDK Integration
Apps using Google Admin SDK, Directory API, Reports API, or any admin-level scope must work through service accounts and domain-wide delegation — not regular user OAuth. The Workspace super-admin must explicitly grant DWD authority in the Google Workspace Admin Console.
Google Workspace Marketplace Listing
Apps distributed through the Workspace Marketplace undergo a separate manual review checking branding, scope consistency, OAuth verification status, app functionality, and UX — before the listing goes live. OAuth verification is a prerequisite, not a substitute for this review. If you would rather hand the whole submission off, our Google API verification service covers OAuth review, restricted scopes, and brand verification end to end.
Workspace Add-ons and Drive Apps
Gmail add-ons, Google Docs/Sheets/Slides add-ons, and Drive apps using restricted scopes must pass OAuth verification AND may also require a CASA Tier 2 security assessment — on top of the Marketplace review if distributing through it. Gmail add-ons and any app that reads mailbox content fall under restricted scopes, so plan for the CASA Tier 2 security assessment for Gmail before you submit.
Enterprise SaaS — Org-Wide Data Access
SaaS tools that read or write Gmail, Calendar, Drive, or Chat data for all users in a client’s Workspace org use service accounts with domain-wide delegation — not per-user OAuth. The approval path runs through the client’s super-admin, not just Google’s verification process.
Domain-Wide Delegation: The Workspace-Only Gate Most Apps Miss
Domain-wide delegation (DWD) lets a service account access data for all users in a Workspace org without individual consent screens. It does not exist in consumer Google OAuth. It only works with Workspace-managed accounts — not personal @gmail.com addresses.
What DWD Requires
- A Google Cloud service account — not a standard OAuth 2.0 Client ID
- The service account’s client ID listed in the Workspace Admin Console
- OAuth scopes explicitly granted to that client ID by a Workspace super-admin
- A Google Workspace domain — does not work for @gmail.com personal accounts
- Only super-admins can enable DWD — not regular admins or domain users
What This Means for Approvals
- Standard OAuth verification does not auto-enable DWD access for any org
- Each client’s Workspace super-admin must manually approve your service account in their own Admin Console
- If a client’s IT policy restricts third-party API access, DWD may be blocked even after your verification passes
- Workspace admins can revoke DWD at any time — immediately ending org-wide access
- The developer project should live inside an organization resource, not a personal Google account
⚠ The DWD Onboarding Trap
Most client onboarding failures for Workspace integrations happen here: the developer has passed Google OAuth verification, but the service account has not been added to the client’s Admin Console with the correct OAuth scopes. Without the super-admin’s DWD grant, the app returns an unauthorized_client error on every API call — even though everything on the Google developer side is configured correctly.
Google Workspace Marketplace Review: The Second Approval Layer
Distributing through the Google Workspace Marketplace requires a separate manual review on top of OAuth verification. This review checks listing quality, branding compliance, and app functionality. Passing one does not satisfy the other.
What the Marketplace Review Checks
- OAuth consent screen set to External (not Internal) and status set to In Production (not Testing)
- App name is 50 characters or fewer and matches the OAuth consent screen name
- All listing links work — privacy policy, terms of service, support URL
- Screenshots accurately show real app functionality — no blurry or staged images
- App must be fully functional — not a work in progress or test build
- No Google trademark misuse in app name, logo, or listing description
- For Drive apps using restricted scopes: CASA Tier 2 security assessment also required Drive apps that request restricted scopes need a security assessment on top of OAuth review, which is exactly why Drive apps face CASA Tier 2.
Common Marketplace Rejection Reasons
- OAuth verification not complete when Marketplace review is submitted
- OAuth consent screen user type set to Internal — blocks all external Workspace users
- Publishing status still set to Testing — must be In Production
- App listing links are broken or point to wrong pages
- App has visible bugs or test data in submitted screenshots
- App name is too generic — vague names like “My Integration Tool” are rejected
6 Mistakes That Stall Google Workspace API Approvals
- Using a standard OAuth 2.0 Client ID instead of a service account for Admin SDK integrations — the two credential types are not interchangeable for domain-level access and this mismatch causes silent authorization failures
- Assuming Google OAuth verification automatically grants DWD access — it does not; each client’s super-admin must separately authorize your service account in their own Admin Console
- Submitting the Workspace Marketplace listing before completing OAuth verification — Marketplace review requires OAuth verification as a hard prerequisite and submissions are rejected automatically without it
- Leaving the OAuth consent screen on Internal user type — this blocks all external Workspace domain users from authorizing the app; must be changed to External before any Marketplace distribution
- Building the developer project under a personal Google account — makes ownership transfer nearly impossible and blocks enterprise resource management features required for Workspace integrations at scale
- Treating the client’s Workspace super-admin as a minor onboarding detail — the super-admin’s DWD grant is a hard technical gate; without it, no amount of Google verification unlocks access inside that org
When All the Gates Are Cleared
- Service account configured in Google Cloud Console with the correct OAuth scopes
- DWD granted by the target org’s Workspace super-admin in their Admin Console
- Google OAuth verification passed — all sensitive and restricted scopes approved
- Workspace Marketplace listing approved — if distributing through the Marketplace
- App accessible to all org users in the domain without per-user consent prompts
Getting all five aligned — across Google’s verification process, the developer project configuration, and each client’s Admin Console — is where Workspace API integrations stall. Each gate is controlled by a different party and must be cleared in the correct sequence. For YouTube-specific quota and compliance support, see the YouTube API approval service page.