Documentation Index

Fetch the complete documentation index at: https://nango.dev/docs/llms.txt

Use this file to discover all available pages before exploring further.

You may also want to visit Google’s OAuth App Verification Help Center besides this guide.

​

Do I need a review?

Most likely, yes. Even if the review would be optional for your app, most teams opt to do it. To know for sure how your scopes are categorized, check your Google cloud console: API & Services -> OAuth consent screen -> Data Access

​

Google App verification

This is a check done by Google to make sure you follow Google’s API rules. Most apps that use Google APIs will do this review. It is one-off. It typically takes < 1 week if you prepare well with this guide.

​

Google App Verification + CASA security assessment

A more complex process that also includes a CASA security assessment. They run in parallel and you need to complete both for your app to be switched to production mode. The security assessment is done by a Google approved vendor. If you prepare with this guide, you can expect 5-20 days from requesting review being fully verified. If you are already SOC 2 type II (or similarly) certified, you have probably done pentests before. 5 days for CASA Tier 2 verification is feasible. If you have never done a security audit, you may need to create the necessary documentation and patch vulnerabilities. Budget 10-20 days. The speed also depends on you: If you fix vulnerabilities fast, and follow up daily with Google and your review vendor, you will be much faster than if you just let things run their course. If you are pressed for time and want more tips to speed things up, reach out to us. We are happy to help 1:1. Google’s Workspace DevRel team can also help with stuck reviews. They can’t change or accelerate Trust & Safety decisions, but they can look into why a review is stuck and sometimes unblock it. If you’re a Nango customer and need an intro, ping us.

​

Recommended process

For App verification + CASA assessment. If you only need to do App verification, skip step 4 and 5.

1. Implement the integration in your app with your Google OAuth app in test mode
   • It’s important the feature works: Google will test it end to end during the App verification
   • 100 users can authorize your app before the review is required
2. Prepare for the App verification (+ CASA assessment)
   • Pick a Google approved CASA vendor (CASA assessment only)
   • Run a first security scan on your app to fix low-hanging fruits (CASA assessment only)
3. Start the app review verification with Google
   • You will need to submit a video walkthrough and answer some questions
   • Google will start reviewing your integration. Expect back & forth on details.
4. Start the CASA assessment (CASA assessment only)
   • If required, Google will email you to request a CASA Tier 2 assessment shortly after you start the review process
   • Forward the email to your CASA vendor
   • Work with your CASA vendor to get validated
5. Letter of validation (LoV) & final approval (CASA assessment only)
   • Your CASA vendor will send an LoV to Google
   • Google will remove the “unverified” screen and unlimited users can authorize
   • Congrats, you are now verified!

​

Step 1: Implement the integration in your app

It’s important to have a working version of the integration before you start the review process. As part of the app verification, Google will test your integration and verify each feature works. They will also check that each scope you request is required by a feature of your integration. For example, if you request https://www.googleapis.com/auth/gmail.send Google wants to see a feature that sends an email on behalf of the user. You can launch your integration while your Google OAuth app is still in test mode, but there are pretty severe restrictions. We recommend you start the app verification process as soon as the integration works end to end. You can polish the UX while the review is in progress.

​

Test mode restrictions

Until your app is verified:

• Users see a scary “this app is unverified” step during the OAuth flow
• Only 100 users may authorize your app in total. You cannot reset this counter or remove test users.
• OAuth tokens always expire after 7 days, forcing users to re-authorize

For apps that need both a Google review and CASA verification these restrictions are in place until both are done.

​

Tips for development

• Only request scopes you need right now. If you need additional scopes in the future, add them then.
  • Google reviewers will test this and reject your application if you ask for scopes you don’t use.
  • This applies to scopes for any of your upcoming features that aren’t shipped yet. Resubmit a supplementary verification when the feature lands.
• Use a separate OAuth app (on a different Google Cloud project) for your own development & testing. It gets its own 100 test users.
• Keep the restricted scopes count minimal and user-scoped.
  • If you ask for 10+ restricted scopes (anecdotal), or domain-wide delegation, Google may ask you to become CASA Tier 3 verified.
  • CASA Tier 3 is exponentially more work and costly, compared to Tier 2.
• Test users are permanent: You cannot reset the counter or remove test users. Make sure you use the 100 test users wisely.
• If your app trains AI on Google user data, only user-specific personal models are allowed. Generalized model training on Workspace user data is prohibited by Google’s Workspace API user data and developer policy, regardless of company size. See AI and data use rules for what you need to disclose.

​

Step 2: Prepare for review

For App verification, make sure you fulfill all of Google’s verification requirements. Both the “Brand verification requirements” and “Sensitive and Restricted Scope Requirements” are relevant (unless you only use non-sensitive scopes).

​

Know these answers before you start

Reviewers will ask each of these, and slow answers stall the review:

• What does the app do and is it an acceptable use case? Anything on Google’s prohibited list won’t get approved no matter how good the rest of your submission is.
• Why each requested scope, and why won’t a narrower one work? See Scope justifications below.
• Who controls DNS for the domains in your submission? Google verifies ownership of your homepage domain and its subdomains, usually via a CNAME or TXT record.
• Who internally owns your privacy policy and public webpages? If a reviewer asks you to update language and your legal team takes weeks, your review takes weeks.

​

Set the right contact email

The contact email on the OAuth consent screen is the only channel Google’s Trust & Safety team uses. They open one email thread per review and ignore anything outside it.

• Use a monitored alias or shared inbox (e.g. oauth-review@yourcompany.com), never a personal address, info@, or sales@.
• Add at least one editor on the GCP project so a second person can see incoming emails.
• Reviews have stalled for weeks because all the listed recipients had left the company. Set yourself a reminder to refresh these addresses before each review and each annual renewal.

​

Verify ownership of your callback domain

Switch to a custom callback URL in Nango, and verify the domain of your callback URL in your Google Cloud project. Domain verification is one of the first checks reviewers run.

​

Make sure to submit the form after changes

Google’s verification form has a known pitfall: when you go back to fix an issue, the “Submit” button sits below the fold. Clicking the per-error “Proceed” buttons updates your answers but does not re-submit. If days pass with no acknowledgement email from Trust & Safety, you probably never submitted. Scroll to the bottom of the form and click Submit.

​

Make sure scopes match between the consent screen and Data Access page

Reviewers check that the scopes on your OAuth consent screen match the scopes on the Data Access page in Google Cloud Console. Any mismatch is a guaranteed rejection, and it also breaks your app at runtime. If you also publish a Workspace add-on or use Apps Script, the scopes in your Marketplace SDK configuration and Add-on manifest must match too.

​

Demo video

Prepare a demo video exactly as Google requests. Any screen recording tool works and production polish isn’t required, but completeness is. Reviewers use it to confirm each requested scope is actually used. The video must show:

• The end-to-end OAuth flow inside your app, including the actual Google consent screen with the exact scopes you’re requesting. A previously approved scope set won’t pass.
• Every feature that uses each requested scope, demonstrated from the user’s perspective.

​

Scope justifications

For each scope, write a justification that names the scope, the feature using it, and why a narrower scope won’t work. One sentence per non-sensitive scope, several for restricted scopes. Sample acceptable: “My app will use https://www.googleapis.com/auth/calendar.readonly to show a user’s calendar data on the scheduling screen so users can manage their schedule and sync with Google Calendar.” Sample unacceptable: “My app wants to show users their calendar.” Too vague, no feature link, no reason narrower scopes fail. The demo video plus the justifications cause most of the back-and-forth. A short screen recording attached to right justification often closes the loop in one round.

​

AI and data use rules

Google’s Workspace API user data and developer policy absolutely prohibits using Workspace user data to train generalized AI or ML models. This applies to every company, regardless of size. User-specific personal models are allowed: for example, an agent only accessible to the user it was trained on. Drafting Gmail replies for a user is allowed but may require a restricted scope. If you use AI on Workspace data, you must:

• Document AI use in the feature itself, in the consent flow, and in any prompt or dialog preceding an ask or transfer.
• Add an affirmative statement to your privacy policy (or homepage) describing the use and confirming you don’t use the data for training. See Privacy policy below.
• Check the Application Use Cases list before building: prohibited use cases will not pass review.

​

Branding and product names

Reviewers will reject submissions that misuse Google product names. Two rules to follow:

• Use the official product name with the trademark symbol on first use: “Google Chat™”, “Google Docs™”, “Google Sheets™”, “Google Drive™”.
• Don’t use descriptive substitutes like “Google’s replacement for Hangouts” or “Google’s current messaging app”. They aren’t trademarks Google recognizes.

Good listing example: “LumApps for Google Chat™”. Check the Marketplace branding guidelines for the rules reviewers enforce. The Google Workspace Partner Advantage program offers further branding support for accepted partners.

​

Homepage requirements

Reviewers will check that your app has a public homepage that is:

• On a domain you own (not a Google Play Store, Facebook, or other third-party page).
• Tied to the product under review. If your homepage is a generic landing page, link from there to a section that describes what the app does and includes its privacy policy.
• Reachable when the review starts (not behind login).

​

Privacy policy

Your privacy policy must include the affirmative statement required by the Workspace API user data and developer policy (the “Limited Use” disclosure) and must clearly disclose how (and where) you store user data. Two patterns Google’s DevRel team highlights as good examples:

• Add a section to your global privacy policy. OpenText added a dedicated “API Services” section that covers all their Google integrations.
• Create a dedicated page. Zoho built a separate Google Workspace privacy page that covers the integrations end to end.

Either approach works. If you train AI on Workspace data (or if reviewers think you might) include an affirmative statement that you don’t use the data for generalized model training.

​

Additional prep for CASA Tier 2 assessment

CASA assessments have different tiers, but the only relevant one for you here is Tier 2.

​

Run a security pre-scan

We recommend running a first security scan before you start your CASA assessment. This lets you fix obvious issues now, without the additional back-and-forth hassle with your CASA vendor. CASA recommends Fluidattacks for static security scans. There is a free, open-source CLI that spins up a pre-configured docker container to run a static (SAST) scan against your codebase. Instructions are here. Ideally, aim for a clean output, but clear at least high and medium threats. Otherwise you will have at least 2 scan cycles during your actual assessment.

​

Pick a CASA assessment vendor

Your vendor must be listed on the CASA Authorized Assessors list. We have compiled a list of the most common vendors: TAC Security (recommended) - $540 - $720 $540 gets you two revalidation. $720 will get you unlimited revalidations. Sometimes runs 10% discounts, check their website. A validation is a single scan and output of issues. If you do a pre-scan and fix issues first, you’ll probably only need the two validations to fix remaining issues. Try to avoid scanning again without a fix or an accepted omission for everything picked up in the first scan. Many Nango customers have used them. They are affordable and have mostly automated the process, but make sure to check in with them daily on their communication with Google. This helps run the review as fast as possible. Netsentries - ~$700 You need to fill in a form to get a full quote. We heard they have a more human-level touch. If you have used them please let us know, happy to add your experience here. Prescient security - $3,000+ Much more expensive but much better support and guidance throughout the process. If you already work with them from your SOC 2 or ISO 27001 audit and want guidance, try them. Prices are as of August 2025, if you have updates, let us know. Engage a vendor before you start your review, so you can avoid delays from back-and-forth negotiations.

​

Step 3: Start the App verification

Ready? Let’s go to prod! In your GCP console go to API & Services -> OAuth consent screen -> Audience Under “Publishing status”, click on “Publish app”. Confirm the consent screen. Now go to Verification Center in the navbar and you should see a form to start the app verification process. You may get emails from Google asking for more details. We recommend answering quickly, but diligently. Google answers within 24-48h, the fewer loops you need, the faster your app will get verified. Note that the test mode restrictions remain until your verification is complete.

​

Step 4: Start the CASA assessment

If a CASA assessment is required, you will get an email from Google shortly after starting the App verification process. If nothing arrives after a few days, reach out to Google. Forward this email to your CASA vendor. Some vendors will only let you start the assessment once they have the email from Google. The CASA Tier 2 assessment has two parts:

1. Security scan (static or dynamic) of your assets
   • You get to pick which assets to scan (API, mobile app, web app, etc.)
   • You usually get the choice between a static (SAST) code scan or a dynamic, automated pen test (DAST)
   • If you pick SAST, you can prepare perfectly with Fluidattacks. The DAST might find slightly more complex issues.
2. Self-Assessment questionnaire (SAQ): About 50 questions on your security practices & setup
   • Mostly “common sense” and a repeat of what you did for SOC 2/ISO, if you have done them
   • The goal here is to answer “yes” for everything with 1-2 sentences of evidence that gives the auditor no reason to reject your questionnaire

Run the security scan and get your results. Fix the issues, or provide explanations for each issue that you deem a false positive of the scan. Make sure you get confirmation from your CASA vendor for the false positives. Repeat until the scan is clean and/or all false positives are approved by your vendor. More tips:

• If your app is SSO only for login, and you picked a DAST scan, let your vendor know. Some DAST tools can’t handle SSO and will report the app as broken immediately. Avoid the extra loop.
• Don’t submit SAQ questionnaires with “no” answers in them. You can’t pass with no, work on getting to yes and save yourself the extra roundtrip.

​

Step 5: Letter of validation (LoV)

Once you pass all steps your CASA vendor will send a letter of validation to Google. Google may take up to one week to process the letter and issue final approval for your app. Don’t panic if your ticket stays open for a few days with no updates. Once verified, Google will remove the “unverified” step from your OAuth flow and lift the 100 test users limit. Congrats, you are now live! 🎉

​

After verification

A few things change once you’re live, and a few things you’ll deal with on every release.

​

Handle granular OAuth consent

As of January 2026, all apps using Google scopes are moved to granular consent: users see each scope as a separate checkbox and can grant a subset of what your app requested. Your app must handle a partial grant cleanly. When a request fails with insufficient_authorized_scopes or a similar permission error, you have three options:

• Show an inline error explaining the missing scope.
• Trigger an incremental authorization request to add the missing scope on the fly.
• Re-check granted scopes on app start and prompt the user to re-authorize anything missing before they hit the broken feature.

Pick the one that makes sense for the feature. Don’t crash, and don’t silently swallow the error — both will surface as user complaints.

​

Adding new scopes later

If you add new scopes after your app is verified, you submit a supplementary verification. CASA usually doesn’t need to be redone within the 12-month validity window, but Google may ask your assessor to spot-check the change if a new restricted scope materially expands what your app can do.