Google OAuth Verification
Meta gives you an appeal form. Google does not. When your OAuth verification is rejected, Google's own Help Centre describes exactly one route back: fix the app, then submit every required material again, from the beginning, on the same project that just failed.
Most teams find this out at the worst possible moment. The rejection email lands, someone searches for the appeal link, and there isn't one. What follows is usually weeks of guessing which of a dozen requirements was the actual blocker — while the app is already degraded for real users.
What a rejection actually does to your app
A rejection is not a neutral "try again later" state. Google is explicit about the consequence:
In practice that means the feature you built the integration for stops functioning for your users, and it stays stopped for the entire length of the resubmission cycle. There is no partial or provisional access while you correct the submission.
Nothing carries over
Google's reapply instruction ends with a sentence teams routinely underestimate: "All required materials need to be resubmitted." The scope justification, the demo video, the consent screen configuration — all of it goes again.
The clock restarts
You do not rejoin the queue where you left it. A resubmission is a fresh review against the full requirement set, not a diff against what you fixed.
The user cap keeps burning
Google states the 100-new-user cap "applies over the entire lifetime of the project, and it cannot be reset or changed." Every rejection cycle spends a resource you can never get back.
Everything runs over email
All review correspondence goes to the project owners and editors listed in Cloud Console — nowhere else. Google calls keeping that list current "critical," and warns that failing to act on notifications "could result in the loss of access to Google APIs."
Why the second submission so often fails too
The reason resubmissions stall is rarely laziness. It is that Google's rejection notice tells you a policy was not met — it does not hand you a line-by-line diff of your submission. Identifying the real blocker means auditing your app against the entire published requirement set and working out which item a reviewer could not verify.
That requirement set is larger than most teams expect. Verified against Google's live documentation, a sensitive or restricted scope submission has to satisfy all of the following simultaneously:
- Homepage. Hosted on a domain you own and have verified, describing what the app actually does. Google states plainly that your homepage "can not be only a login page."
- Privacy policy. Hosted on the same domain as the homepage, linked from the homepage, linked from the consent screen — and the two links must be identical.
- Domain ownership. Every authorised domain verified in Google Search Console, by an account listed as a project owner or editor.
- Scope justification. A written explanation of why a narrower scope would not work, including what specifically would break. Google: "If your justification is deemed insufficient, your app verification request may be rejected."
- Demonstration video. Must show the end-to-end flow including the OAuth grant, the same app name and branding you submitted, and the complete consent screen displaying the exact scopes requested — with the consent screen language toggled to English.
- Use case. The app's functionality itself is assessed for whether it is an appropriate use of the data. A technically perfect submission for a use case Google does not consider appropriate does not pass.
- Branding. Buttons that initiate a Google action must follow Google's branding guidelines, including any product-specific ones.
- Project hygiene. For restricted scopes, every OAuth client inside the project is in scope. Google's own suggestion: "delete or remove OAuth Clients that are not ready for production before submitting."
Any one of these can be the reason. Several of them fail silently — a privacy policy link that differs by a trailing slash, a demo video recorded in a non-English console, a leftover test OAuth client in the project from two years ago.
How the resubmission path is structured
Establish what was actually assessed
Brand verification, sensitive scope verification and restricted scope verification are three distinct reviews with different criteria. Knowing which one rejected you determines everything that follows.
Audit the app against the full requirement set
Not against your reading of the rejection email. This is the step that decides whether cycle two succeeds, and it is the step most teams skip.
Fix the product, not just the paperwork
Some rejections are documentation problems. Others require changing which scopes the code requests, or adding a user-facing feature that makes the data use prominent. Those are engineering changes, not form edits.
Rebuild the evidence package
A new demo video that matches the current app and current scope list, a rewritten justification that answers the narrowest-scope question directly, and consent screen configuration that matches what the code actually requests.
Resubmit and hold the thread
Reselect the scopes on the consent screen page and submit for verification. From there it is an email conversation with the review team, and how you answer their follow-ups shapes the timeline.
A conflict worth knowing about before you plan around a date
Google publishes review time estimates in one place — brand verification 2–3 business days, sensitive scope verification 10 business days, restricted scope verification 6 weeks — and immediately labels them as estimates only, stating that they "will vary based on developer responsiveness." Other Google pages state different figures for the same review. Treat any single number you read online, including these, as an estimate rather than a commitment.
The failure mode nobody expects: approved, still broken
A related case that looks like a rejection but is not. Google documents that verified and approved apps can still show users the unverified screen or a sign-in-disabled message. The cause is that the app is requesting a scope in code that was never approved during verification.
The fix is a reconciliation between your codebase and your Cloud Console scope list. If a scope is not needed, remove it from the code. If it is needed, it has to be added and verified before any call is made against it. Teams often spend weeks debugging an authentication problem that is actually a configuration mismatch.
Where this becomes worth handing off
The economics are straightforward. A restricted scope cycle is measured in weeks, the user cap does not refill, and the feature is offline for real customers the whole time. A second rejection is meaningfully more expensive than the first.
What we do on this is review preparation: auditing the app, consent screen, homepage, privacy policy and scope set against the current published requirements, identifying the likely blocker before you spend another cycle discovering it, and preparing the submission materials so the resubmission is a considered one rather than a repeat. We also handle the correspondence with the review team, which is often where the real decisions get made.
No specific outcome can be guaranteed — Google's review team decides, and the criteria are theirs. What is controllable is that you do not spend a cycle failing on something that was findable in advance.
Related reading: the full Google OAuth verification process, what the unverified app warning actually means, and the consent screen errors that get mistaken for review failures. If you are already in a rejection loop, the approval support services page explains how the engagement works.
Sources: Google Cloud Platform Console Help — OAuth App Verification FAQ, Verification Requirements, and Submitting Your App for Verification. Verified 31 July 2026. Platform requirements change; check the current documentation before acting on any specific point.