Short answer: To get Google OAuth approval, first check whether you qualify for one of Google’s verification exceptions, because many internal tools do. If you don’t, identify whether your scopes are sensitive or restricted, since restricted Gmail scopes add a third-party security assessment on top of verification. Then choose between running your own Google Cloud project and building on a pre-verified one.
Most teams find out about Google’s verification requirements after the integration already works. The code runs, test accounts connect, and then someone tries to move past a hundred users and hits a wall that takes weeks to clear.
Google’s verification and security assessment processes can take several weeks or longer. The work is not hard, but it is sequential, and it sits between your finished feature and your production launch. Here is how to figure out which version of that process applies to you, and what your options are.
First, check whether you need verification at all
A lot of teams start the verification process before confirming they need it. Google publishes exceptions, and several are common:
Apps for personal use with fewer than 100 users
Apps set to Testing rather than In production
Apps configured to work only with internal Google accounts inside your own organization
Apps that a Google Workspace admin has allowed
If you are building an internal tool for your own Workspace domain, or a prototype that will never touch more than a handful of mailboxes, you are likely covered by one of these. Treat the limits as ceilings rather than loopholes. The 100-user threshold arrives faster than teams expect, and Testing mode is not somewhere a customer-facing product can live.
Everyone else needs to know which scopes they are asking for.
What triggers verification, and what triggers a security audit
Google sorts scopes into sensitive and restricted, and the two carry different obligations.
Sensitive scopes require Google verification. Your application has to follow Google’s API Services User Data Policy. This covers most calendar and contacts work, plus sending mail:
gmail.send, calendar, calendar.readonly, calendar.events, calendar.events.readonly, contacts, contacts.readonly, contacts.other.readonly
Restricted scopes require verification and a separate security assessment. These are the Gmail scopes that read, write, or modify mailbox data and settings:
If you request a restricted scope, your app also goes through CASA (Cloud Application Security Assessment). Google assigns one of two assurance levels, AL1 or AL2, based on the scopes you request, your user count, and other risk signals. Many guides still use the older Tier 2 and Tier 3 labels. Either level means hiring a Google-authorized third-party assessor, remediating whatever they find, and repeating the assessment every year to keep your verified status. It is the single largest line item in most Gmail integration timelines.
Two details worth knowing before you pick scopes. The gmail.labels scope is neither sensitive nor restricted, so it needs no verification or assessment at all. And Nylas does not allow the all-access mail.google.com scope. Google reviews it more strictly than any other Gmail scope and expects most apps to request granular scopes instead.
The practical takeaway: request the narrowest scopes your features actually use. A calendar integration and an email integration are not the same amount of work, and asking for gmail.modify when gmail.send covers your feature moves you from a verification review into a security audit.
Three ways to get Google OAuth for your application
Own Google Cloud project
Nylas Shared Google App
Nylas sandbox credentials
Consent screen shows
Your brand
Nylas
Nylas
Verification owner
You
Nylas
Nylas
CASA assessment
You, annually
Nylas, already complete
Not applicable
Custom auth hostname
Supported
Not supported
Not supported
Suitable for production
Yes
Yes
No
Run your own Google Cloud project
You create the project, enable the APIs, configure the consent screen, request your scopes, and submit for verification. If you request restricted scopes, you engage an assessor and complete CASA.
This is the right answer when your brand needs to be on the consent screen, when compliance requires credential isolation, or when you want a custom hosted authentication hostname. You connect it to Nylas by creating a connector with your own client_id and client_secret, which is also where you set the Pub/Sub topic_name that powers native Google push notifications.
The cost is time and ongoing ownership. Verification is not a one-time event. You monitor Google’s policy changes, maintain your verified status, and repeat the CASA assessment annually if restricted scopes are in play.
Build on the Nylas Shared Google App
Nylas maintains a Google Cloud project that has already been validated at AL2, the highest CASA assurance level (formerly called Tier 3). Enabling it on your Google connector points your authentication at that verified application instead of one you build and verify yourself. There is no Google Cloud project to create, no consent screen to configure, and no verification queue to wait in. You can go live with Google authentication the same day you turn it on.
You still choose your own scopes in the Nylas Dashboard, and Nylas handles every annual re-assessment.
Three tradeoffs to weigh before you commit:
Your users see Nylas on the consent screen, not your company name.
It does not work with a custom hosted authentication hostname. The OAuth client belongs to Nylas, so you cannot add your own callback URI to it, and the flow fails with redirect_uri_mismatch. Whitelabeling the auth flow requires your own Google Cloud project.
Switching means re-authenticating. If you already have users authenticated through your own project, moving them issues new grant IDs, and your application needs to handle that.
The Shared Google App is a paid add-on. Ask your account manager or the Nylas sales team whether it is available on your plan.
Default Nylas credentials, for development only
Without a connector, you can still build and test against Nylas’ default shared credentials. This is how most teams get their first grant working in minutes, and it is how the Nylas CLI connects accounts during setup. It is a development path. Production applications should be on either your own Google Cloud project or the Shared Google App. The default credentials run on a separate Google Cloud project from the Shared Google App, and the two are isolated, so nothing that happens on the development credentials can affect the Shared Google App.
What are the risks of building on a shared Google Cloud project?
Building on someone else’s verified application introduces a dependency, and it is fair to ask what that dependency costs.
The two questions worth asking a provider are what happens to your application if their verification status changes, and whether you can leave. For Nylas, the answers are that the Shared Google App holds an AL2 validation and Nylas carries the annual renewal obligation, and that you can move to your own Google Cloud project whenever you want. You create your own auth app, update the connector credentials, and existing grants keep working until users re-authenticate. You can also run both configurations at once using multiple provider applications, which lets you migrate gradually instead of cutting over.
That exit path is the part to check with any vendor offering this. A shared OAuth application you cannot leave is a different product from one you can.
Two more things are worth knowing about how the Shared Google App is set up. It runs on its own Google Cloud project, isolated from the default development credentials, so misuse on the free development path cannot put its verified status at risk. And Google attributes API quota to the project that owns the OAuth client, so every application on the Shared Google App draws from the same per-project limit. Nylas can request higher limits from Google as usage grows, and can spread applications across additional projects if adoption calls for it. If you expect heavy volume, raise it with the Nylas team when you evaluate the add-on.
Should you use your own Google Cloud project or a shared one?
Pick your own Google Cloud project if any of these are true: your brand has to appear on the consent screen, you need a custom hosted authentication hostname, or credential isolation is a compliance requirement.
Pick the Shared Google App if your launch date is the binding constraint, if restricted Gmail scopes put a CASA assessment on your critical path, or if you would rather not own an annual audit cycle.
Either way, decide before you build the auth flow. The decision is reversible, but reversing it means every connected user re-authenticates.
Frequently asked questions
Do Nylas customers share a Google Cloud project?
Only if they choose to. Customers can connect their own Google Cloud project through a connector, or enable the Nylas Shared Google App, which routes authentication through a Nylas-owned project validated at AL2, the highest CASA assurance level. Both are supported production configurations. Applications on the Shared Google App share that project’s API quota, and the default development credentials run on a separate, isolated project.
How long does Google OAuth verification take?
Google’s verification and security assessment processes can take several weeks or longer, and the timeline depends on which scopes you request. Sensitive scopes require verification only. Restricted Gmail scopes add a CASA security assessment conducted by a third-party assessor.
Why do users see “Google hasn’t verified this app”?
That screen appears when your OAuth application requests sensitive or restricted scopes and has not completed verification. Users can click through it, but it is not something to ship to customers. It usually means your app is still in Testing, or that a verification submission is pending or was rejected. If you are testing on a Nylas Sandbox account, you will also see a separate Nylas warning.
What happens if Google rejects your verification submission?
You resubmit after fixing what the reviewer flagged. Common causes are a demo video that does not show the full OAuth consent flow, a “Sign in with Google” button that does not meet Google’s branding guidelines, and requesting scopes broader than your demonstrated use justifies. If you use Nylas Hosted authentication, configure the OAuth login prompt with select_provider or detect,select_provider. Passing a login_hint without a prompt sends users straight to the Google consent screen without the branded button, which can delay or fail verification.
Do I need a CASA assessment for a calendar integration?
No. Calendar and contacts scopes are sensitive, not restricted, so they require Google verification without a security assessment. CASA applies to the restricted Gmail scopes, such as gmail.readonly, gmail.modify, and gmail.compose.
Can I switch from the Nylas Shared Google App to my own project later?
Yes. Create your own Google auth app and update your connector credentials. Existing grants continue working, and users move to the new credentials when they next re-authenticate. You can also run both side by side while you migrate.
What happens if I request the mail.google.com scope?
Nylas does not allow it. Google reviews the all-access scope more strictly than any other Gmail scope and expects most apps to request granular scopes instead.
Working out which path fits your integration? Talk to the Nylas team about your scopes and your timeline.
Email and Contacts API 
Calendar API & Scheduler 
Notetaker API 
Agent Accounts 
Sales & CRM 
Recruiting & ATS 
Healthcare
Financial
Legal
Real Estate
Education
Field Services
Docs
SDKs
Guides
Integrations
API status
Changelog
Support
Professional Services
