This is why so many teams get blindsided late. The architecture is finished, the integration works, and only at the consent-screen stage does someone notice the scope they picked is marked restricted. At that point the choice is either a scope migration through code that is already written, or an annual security assessment nobody budgeted for.

The three tiers, and what each one really costs

The gap nobody warns you about: there is no official sensitive-scope list

Google publishes a complete, maintained list of restricted scopes. It publishes nothing equivalent for sensitive scopes — only scattered examples. Worse, the Google API Services User Data Policy still links to an old help article as the authoritative definition and as the current list of sensitive and restricted scopes, and that article now redirects to a page that contains neither the anchors nor the lists. The policy document’s own definitional links are dead.

The practical consequence: the only reliable way to know your tier is to add the scope in the Cloud console and read the label it applies. Every list you find in a blog post, including a list of sensitive scopes presented as complete, is somebody’s reconstruction.

What each tier triggers

What goes wrong while you are unverified

Three separate penalties apply, and teams routinely diagnose them as bugs rather than as policy.

• The unverified app screen appears — and it also appears when the scopes requested in your code simply differ from the scopes configured on the consent screen. That mismatch alone is enough.
• A cap of 100 new users applies to apps showing that screen, and Google states the cap runs over the entire lifetime of the project and cannot be reset or changed.
• In Testing publishing status, authorisations expire seven days after consent, and any refresh token issued expires with them. The exception is narrow: apps requesting only name, email, profile or the OpenID Connect equivalents. Request any other scope and the exception stops applying.
• If an app is rejected for sensitive or restricted scopes, user access to those unapproved scopes through OAuth stops working.
• Request a broader scope than your feature needs and Google directs you to a narrower one before verification proceeds. If the justification is judged insufficient, the request may be rejected outright.
• Exhausting the user cap while unverified can result in Google sign-in being disabled for the project.
• Adding a new redirect URL, a new JavaScript origin, or changing the product name after verification sends the app back through verification.
• Adding a restricted scope after an assessment may require the assessment to be redone to cover it.

The moving target: your tier can change without you touching anything

Google states plainly that it continuously re-evaluates the risk of user data access and may upgrade certain data types and scopes to sensitive or restricted. When that happens, apps already using those scopes become unverified. Google says a grace period is given before the unverified screen and the user cap apply — but never says how long that grace period is. An integration that shipped compliant can become non-compliant on Google’s schedule, not yours.

How to work out where you actually stand

1. Enumerate every scope your code requests, not every scope you configuredThese drift apart constantly, and the drift itself is a documented cause of the unverified screen. The list in your OAuth client and the list in your codebase must match exactly.
2. Add each one in the console and read the labelThis is the only authoritative classification. Do not infer a tier from the API name — sibling scopes on the same API frequently land in different tiers.
3. Test whether an exception applies before assuming a review is inevitableGoogle documents four: personal use, development and testing, service-owned data with no user data, and internal-only use inside your own Workspace or Cloud Identity organisation. Each carries its own trade-offs, and the caps and token limits do not disappear in the first two.
4. Attack the scope list before you attack the paperworkThe single highest-leverage move is narrowing scope until the restricted tier no longer applies. Google’s own worked example is a team using the full mail scope purely to send messages — a minimum-scope violation, resolved by migrating to gmail.send, which is sensitive rather than restricted. That one migration removes an annual assessment permanently.
5. Only then write the justification and record the demonstrationGoogle requires an explanation of why narrower scopes would not work, with specifics on what functionality would break. Generic requests, and requests written to future-proof access you have not built yet, are what get sent back.

Where projects stall

• The scope tier was assumed from the API name, so a restricted requirement surfaced after the architecture was locked.
• A blog post’s sensitive-scope list was treated as complete, and the console said otherwise.
• The team read Google’s published timeline estimates as commitments — Google attaches its own caveat that they are estimates only and vary with developer responsiveness, and two current Google pages state different figures for the same review.
• The scopes in code and the scopes on the consent screen drifted apart during development, producing the unverified screen with no other fault present.
• Testing status was used as a long-term staging setup, and the 7-day authorisation expiry was diagnosed for weeks as a token-refresh bug.
• The user cap was quietly exhausted during a beta, and sign-in stopped for new users with no way to reset it.
• A justification was written describing the product rather than the specific data the scope reads and why a narrower scope cannot deliver the feature.
• Nobody checked whether a Workspace administrator had blocked the app — a verified status does not override an administrator’s own settings.

The part that is genuinely hard

Reading a label in a console is not the work. The work is the decision that comes after it: whether the feature can be rebuilt on a narrower scope, what that costs in engineering time against a recurring annual assessment, and how to write a justification that ties one specific scope to one specific user-visible function in language a reviewer accepts without a follow-up. Get that wrong and you are not rejected once — you are in a correspondence loop, with the user cap filling up underneath you the whole time. Scope architecture, justification drafting and review preparation are what we do for clients, and they are deliberately not what this article hands over.

Related reading: the full Google OAuth verification walkthrough, what the unverified app warning means and how to remove it, and what the CASA security assessment actually asks of Gmail API apps.