Google API Verification Service
OAuth app verification, sensitive and restricted scope review, brand verification, and the CASA security assessment — prepared and submitted properly, so your app stops showing the unverified warning and your launch stops waiting on Google.
Who this is for
You have a working Google API integration and Google is standing between it and your users. Maybe the consent screen shows an unverified app warning. Maybe your scopes turned out to be restricted and a security assessment appeared out of nowhere. Maybe your submission keeps coming back for a reason nobody on the team can decode.
This is not a tutorial service. It is the submission handled by someone who has read the policy pages and done this before.
What is covered
OAuth app verification
Sensitive and restricted scope review — scope justification, demo video, and the documentation Google actually asks for. Background: the sensitive and restricted scope review.
Brand verification
App name, logo, homepage and authorized domains are checked separately from scopes. Any branding change forces a resubmission. See why branding gets rejected.
Restricted scopes and CASA
Gmail and Drive restricted scopes trigger a CASA Tier 2 security assessment by an approved assessor. See the Gmail and Drive paths.
Consent screen and config errors
redirect_uri_mismatch, admin_policy_enforced, org_internal, disallowed_useragent — diagnosed against the actual cause, not the banner. See the error reference.
Removing the unverified warning
The warning is a symptom of the scopes you request. Removing it means a verification request, not a settings toggle. See what the warning means.
Google Workspace apps
Workspace Marketplace and admin-controlled access follow a different path from a standard consumer OAuth app. See why it is different.
Working on the video side instead? That is handled on the YouTube API approval service page.
Why Google submissions stall
- The scope list is wider than the product. Google evaluates whether each requested scope is necessary for the feature you describe. One scope you do not really use can sink the whole submission.
- The demo video does not show the scope being used. Reviewers need to see the data being accessed inside your product, not a slideshow of the feature.
- The homepage and privacy policy do not match the app. Domain mismatches, missing disclosures, and a privacy policy that never mentions Google user data are routine rejection causes.
- Restricted scopes were not planned for. A CASA Tier 2 assessment is a security review with cost and lead time. Teams discover it after the code is written.
- The app is stuck behind the unverified screen. Google caps apps showing that screen at 100 new users — for the lifetime of the project, and it cannot be reset.
- Testing mode ran out. Testing publishing status is limited to 100 test users, and a test user authorization expires seven days after consent.
How the work runs
Audit
Your Cloud project, OAuth client, scope list, consent screen, publishing status and audience are reviewed against what your product actually does.
Reduce and justify
Scopes are trimmed to what the feature genuinely needs, and each remaining scope gets a justification a reviewer can accept.
Fix the surrounding requirements
Homepage, privacy policy, authorized domains, domain ownership in Search Console, branding assets — the parts that fail quietly.
Demo video and submission
A screencast that demonstrates each requested scope in use, then the submission itself, tracked through review.
Security assessment, if triggered
If restricted scopes are in play, you are guided through the CASA process and the evidence the assessor will ask for.
An honest note. Google reviews and approves apps independently. No consultant controls that decision, and nobody can promise an outcome or a timeline. What can be controlled is that your submission is complete, your scopes are defensible, and your evidence is what the reviewer needs — which is what removes the avoidable rejections. This service is not affiliated with or endorsed by Google LLC.
What you provide
Access, not passwords
Role-based or temporary access to the Google Cloud project. Passwords are never requested or stored, and access is revoked when the project ends.
A working app
Reviewers must be able to reach and use the feature. An integration that cannot be demonstrated cannot be approved.
The real use case
What data you access, why, and what you do with it. Accuracy here is what makes the scope justification hold.
Domain control
Ownership of the homepage domain, so it can be verified in Search Console where required.
Frequently asked questions
Does every Google app need verification?
No. Apps requesting only name, email and profile scopes, or using Sign in with Google, do not show the warning and do not need users on a test list. Verification is triggered by sensitive and restricted scopes — and by wanting your app name and logo on the consent screen.
How long does Google verification take?
It varies by scope type and by how complete the submission is. Brand verification is typically faster than a restricted-scope review with a security assessment behind it. Google publishes no committed timeline and none can be promised here.
What is CASA Tier 2?
A security assessment carried out by a Google-approved assessor, required for apps using restricted scopes such as certain Gmail and Drive scopes. It has its own cost and lead time, separate from the OAuth review.
Can you fix an app that was already rejected?
Yes — that is most of this work. The first step is reading the actual rejection reason rather than guessing, then correcting the scope list, the evidence, or the surrounding requirements before resubmitting.
Do you need my password?
No. Developer or role-based access to the Cloud project is enough, and it should be temporary. Passwords are never requested.
Stuck on Google verification?
Send the rejection email or a screenshot of the consent screen, and you will get a straight answer on what is actually blocking it.
Requirements described here reflect Google official documentation — Using OAuth 2.0 for Web Server Applications, Manage OAuth Clients, Manage App Audience, Manage OAuth App Branding, and the Unverified apps support article — reviewed July 2026. Google policies change; verify against the current documentation. This is technical implementation and submission support, not legal advice, and it is not affiliated with or endorsed by Google LLC. Google makes all verification and enforcement decisions independently.