Your app is stuck — and the warning screen is why
You built an app, connected it to a Google API, and now every user sees “This app isn’t verified” before they can log in. Or worse: you have already hit the 100-user ceiling and new users simply cannot connect. This is Google’s unverified app gate — and it does not go away on its own.
What “This App Isn’t Verified” Actually Means
The warning screen appears when your app requests sensitive or restricted OAuth scopes — such as Gmail, Google Drive, Google Calendar, or Google Contacts access — without having completed Google’s OAuth app verification. It is not a bug. It is an enforced policy gate that Google applies to protect users from apps that have not been reviewed.
Once the warning is triggered, two things happen: users see a warning screen before the OAuth consent page, and your app hits a hard 100-user lifetime cap. That cap is permanent on the project — it cannot be reset by creating a new OAuth client ID or redeploying the app. The only exit is verification.
⚠️ The 100-User Cap Is Permanent and Cannot Be Reset
The 100 new-user limit applies across the entire lifetime of the Google Cloud project. It cannot be reset, worked around, or extended. Switching OAuth client IDs within the same project does not help. Once you hit it, new users cannot authorise your app until verification is complete.
Which Scopes Trigger the Warning
✅ No warning — non-sensitive
email, profile, openid — basic identity scopes. These do not require verification and do not show a warning screen to users.
⚠️ Sensitive scopes
Gmail read/send/modify, Google Drive file access, Calendar events, Contacts, Sheets data, Admin SDK data. These require Google sensitive scope verification before wide deployment.
🔴 Restricted scopes
Full Gmail access, full Drive access, and other high-risk data scopes. These require a CASA Tier 2 third-party security assessment before Google will even begin their own review.
Why This Catches So Many Teams Off Guard
Common Scenarios Where the Warning Appears
- Internal tool moved to external users — Your app worked fine as “Internal” within your Workspace organisation. Once the audience is changed to “External,” Google’s unverified app rules apply immediately for any sensitive scopes in use.
- New scope added to a live app — An existing verified app adds a new sensitive scope (for example, Gmail send access) without completing re-verification. The warning reappears for new users until the updated scope set is verified.
- SaaS product launch hits the cap — A developer app in testing crosses the 100-user mark just as the product goes live. New signups see the warning screen and cannot authorise, blocking onboarding entirely.
- Inherited app from another team — A new engineering team takes over a product built with sensitive scopes and discovers the previous team never completed verification.
- Google Apps Script shared externally — A script that reads Gmail or Google Calendar data is shared beyond the developer’s own account and immediately triggers the unverified app gate for all other users.
What Google’s Verification Process Actually Involves
Removing the warning requires completing Google’s OAuth app verification — a multi-stage review that goes well beyond filling in a form. Here is what it demands at each stage:
Domain Ownership Verification
Every domain referenced in your OAuth consent screen — homepage URL, privacy policy, terms of service, authorised redirect URIs, and JavaScript origins — must be verified through Google Search Console under the same Google account. Missing even one domain causes an immediate rejection at submission.
OAuth Consent Screen Completeness
App name, support email address, homepage URI, privacy policy URI, and Terms of Service URL must all be accurate, live, and consistent with one another. Any mismatch between your display name and your domain, or a privacy policy URL that returns a 404, blocks progression. If users hit an error on the consent screen instead of the warning, our breakdown of common Google OAuth consent screen errors explains what each message means and who has to fix it.
Privacy Policy Requirements
A generic privacy policy is not sufficient. The policy must specifically describe how your app accesses, uses, stores, and shares Google user data — with language that maps to each requested scope. A privacy policy written before the Google API integration was added will fail this check.
Brand Verification
Google reviews the consent screen branding first. Before the warning clears, Google reviews your app public identity, and here is how Google reviews your app name, logo, and homepage. This step typically takes 2–3 business days when all information is accurate and consistent. Any inconsistency between your app name, logo, and homepage sends the submission back without advancing to scope review.
Scope Justification and Demo Video
For sensitive scopes, Google requires a detailed written justification for each individual scope — explaining precisely why the scope is needed for the app’s core function and how users benefit. A video demonstration showing every step of the user journey for each requested permission is also required. Vague justifications or an incomplete demo video result in rejection.
CASA Security Assessment for Restricted Scopes
Apps requesting restricted scopes must first complete a CASA Tier 2 security assessment conducted by an approved third-party lab before Google begins their own review. This adds significant time and cost to the process and must be completed before the verification submission even opens for restricted-scope apps.
What Causes Verification Submissions to Be Returned or Rejected
Common Reasons Google Returns Applications
- Domain not verified in Google Search Console — The most frequent technical blocker. Every domain referenced anywhere in the project must be verified before submission, including redirect URI domains that developers often overlook.
- Privacy policy does not mention Google data handling — A generic policy that does not specifically address how your app accesses, stores, or shares Gmail, Drive, or Calendar data will fail Google’s policy compliance review.
- Scope justification is too general — Explanations like “we need this to improve the user experience” are rejected. Google expects a specific use-case description tied to each individual permission requested.
- Demo video does not cover all scopes — If the video shows only part of the user flow or skips demonstrating how a specific permission is used in practice, reviewers cannot verify legitimate need for that scope.
- Requesting broader scopes than needed — Google’s minimum-scope policy requires requesting only the narrowest access that supports the functionality. Requesting full Drive access when read-only access would suffice is a standard rejection reason.
- Branding inconsistency — The app name on the consent screen does not match the homepage, or the logo was recently changed without re-verification. Causes brand verification to fail before scope review is even reached.
Why Teams Get Stuck in Multiple Rejection Cycles
The verification requirements interact with one another in ways that are not always obvious from the documentation. A privacy policy that satisfies a legal team may still fail Google’s scope-specific disclosure check. A demo video that clearly shows the application’s workflow may not demonstrate each requested permission in the individual way Google’s reviewers expect.
Most teams discover — only after an initial rejection — that they also have incomplete domain verification, a scope set wider than their actual use case, or a privacy policy that predates their Google API integration. Fixing one issue and resubmitting means cycling back through the review queue each time, with each cycle adding weeks to the timeline while the 100-user cap continues to block new users.
For a detailed breakdown of the full sensitive and restricted scope verification process — including the complete CASA path and what the scope application form actually requires — see the Google OAuth Sensitive and Restricted Scope Verification Guide (2026).
If your app also uses YouTube Data API and you are running into quota or compliance audit requirements, the verification processes overlap significantly — see the YouTube API Approval Service for how these reviews interact.
For a full overview of API approval and verification support services available, visit the Services page.
Need to Remove the “App Isn’t Verified” Warning?
Get expert preparation support for your OAuth consent screen, domain verification, privacy policy, scope justifications, and demo video — so your verification submission is complete and correct the first time.