LinkedIn
Instagram
WhatsApp
Telegram
Google Calendar
Join Slack CommunityGoogle OAuth Verification & Gmail API Credentials
Step-by-step: create Gmail API OAuth credentials, pass Google app verification and CASA Tier 2 review - or ship today on Unipile's already-certified OAuth key and certify your own later.
// Skip the Google Cloud setup entirely.// Unipile's certified OAuth key handles it. const response = await fetch('https://api.unipile.com/api/v1/hosted/accounts', { method: 'POST', headers: { 'X-API-KEY': process.env.UNIPILE_API_KEY, 'Content-Type': 'application/json' }, body: JSON.stringify({ type: 'GOOGLE', name: 'user-123', expiresOn: '2026-12-31' })}); const { url } = await response.json();// Redirect your user to `url` - done.What Google OAuth verification actually is
Google OAuth verification is the formal approval process through which Google confirms that your application handles user data in accordance with its policies. Until your app passes this review, it is considered unverified - meaning users see a warning screen and you are limited to 100 test users maximum. The review is mandatory whenever your app requests sensitive or restricted Gmail API scopes from external (non-internal) users.
Sensitive scopes: what they are
Sensitive scopes allow your app to read or modify user data beyond basic profile information. For Gmail, these include:
gmail.readonly- read all messagesgmail.send- send email on behalf of usergmail.modify- read, compose, archivemail.google.com- full access (restricted)
Sensitive scopes require a Google security assessment. Restricted scopes (like full IMAP access) additionally require a CASA Tier 2 audit. See the full scope reference in our Gmail API Scopes Guide.
Why Gmail API always triggers it
Unlike a basic Google Sign-In flow (which only requests profile data), the Gmail API always requests scopes that grant access to the contents of a user's mailbox. Google treats any mailbox-level permission as sensitive by definition.
This means: every developer who wants to use the Gmail API for external users must go through Google OAuth app verification - there is no version of the Gmail API that bypasses this requirement for production use.
Not sure whether you need OAuth credentials or a simple API key? Read our Gmail API Key vs OAuth guide.
Key distinction: Google OAuth verification is not a one-time event. If you add new scopes to an already-verified app, you must submit the app for re-review covering those additional scopes. Plan your scope strategy before starting the process - it saves weeks.
Weeks of verification.
Use Unipile's key and start now.
Don't lose customers waiting on Google's review. Connect Gmail accounts in 5 minutes with our pre-verified developer credentials.
How to get Gmail API credentials: step-by-step
Getting Gmail API OAuth credentials requires six distinct steps in the Google Cloud Console. Here is the full sequence - from creating your project to holding a working client_id and client_secret.
- Create a Google Cloud project - your isolated billing and API container.
- Enable the Gmail API - activate the API in the API Library for your project.
- Configure the OAuth consent screen - choose app type (external vs internal), fill in app name, support email, and authorized domains.
- Add scopes - select the Gmail scopes your app needs; this determines whether a security review is required.
- Create an OAuth Client ID - choose application type (Web, Desktop, or iOS/Android) and register your redirect URIs.
- Submit for verification - if your app is external and uses sensitive scopes, submit via Google's verification portal.
Go to console.cloud.google.com, click the project picker in the top nav, and select "New Project". Give it a name that reflects your product - it will appear on the OAuth consent screen users see.
Enable billing on the project even if you expect to stay within free quotas. Many APIs (Gmail included) require a billing account to be attached before they can be activated, even at $0 usage.
Google Cloud Console: create a new project via the project picker in the top navigation bar.
In the Google Cloud Console, navigate to "APIs & Services" > "Library". Search for "Gmail API" and click "Enable". You will also likely want to enable the Google People API if you need contact data alongside email.
After enabling, the Gmail API appears in your "Enabled APIs" dashboard. API calls without valid credentials will return a 403 accessNotConfigured error even at this stage - credentials come next.
Google API Library: search for "Gmail API" and click Enable to activate it for your project.
Go to "APIs & Services" > "OAuth consent screen". Choose your user type:
- Internal - only users within your Google Workspace organization. No verification required.
- External - any Google account. Verification required for sensitive/restricted scopes beyond 100 test users.
OAuth consent screen: choose Internal (Workspace-only) or External (any Google account) as your user type.
Fill in the App name, User support email, and developer contact email. These fields appear on the consent screen users see when authorizing your app. Add your authorized domain (the domain of your homepage and privacy policy URL).
For a focused walkthrough of every field, the 100-user cap, and the Internal vs External choice, see our consent screen setup guide.
App Information: fill in the app name, logo, and support email exactly as they should appear on the consent screen.
App Domain: provide live URLs for your homepage, privacy policy, and terms of service. Google's review team checks these.
Authorized Domains: add the root domain of your app. Only URIs from this domain can be used as redirect URIs.
Developer contact information: Google uses this email to notify you about changes to your app's verification status.
Tip: the "App domain" section accepts multiple links (Homepage, Privacy Policy, Terms of Service). Google's verification team will check that these URLs are live and reflect the scopes you are requesting. A missing or broken privacy policy URL is one of the most common reasons verifications are rejected.
In the consent screen configuration, click "Add or Remove Scopes". Use the filter to find Gmail scopes. The scope you choose has a direct impact on your verification path:
gmail.sendorgmail.readonly- sensitive, requires security assessment.gmail.modifyormail.google.com- restricted, requires CASA Tier 2 in addition.openid email profileonly - no verification needed (basic sign-in).
Add or Remove Scopes: select the Gmail scopes your app requires. Scope selection directly determines your verification track.
Plan scope selection carefully. Adding a restricted scope later means re-submitting the entire app for an additional CASA Tier 2 review. For the full scope reference and which APIs each scope unlocks, see our Gmail API Scopes Guide.
Go to "APIs & Services" > "Credentials" > "Create Credentials" > "OAuth Client ID". Select your application type:
- Web application - for server-side apps. Register your redirect URIs (e.g.
https://yourapp.com/oauth/callback). - Desktop app - for installed applications. Uses loopback redirect.
- iOS / Android - mobile apps, uses custom URI schemes.
Credentials panel: select "OAuth Client ID" to generate the client_id and client_secret your app needs.
After creation, download the JSON credentials file. It contains your client_id, client_secret, and registered redirect URIs. Store it securely - never commit it to source control.
For a deep-dive on the difference between this credential type and a simple API key, see our Gmail API Key vs OAuth credentials guide.
Access tokens and refresh tokens: when a user completes the OAuth flow, you receive a short-lived access_token (valid ~1 hour) and a refresh_token (long-lived, stored server-side). Your server uses the refresh token to obtain new access tokens without re-prompting the user. Always request access_type=offline and prompt=consent on the first authorization to receive the refresh token. Store refresh tokens encrypted at rest.
For a broader look at how OAuth fits into email API architecture - including sync strategies and provider differences - see our OAuth Email API guide.
Use Unipile's keyThe "This app isn't verified" warning, the 100-user cap & exemptions
Before your app passes Google OAuth app verification, every user who tries to authorize it sees a warning screen. Google also enforces a hard 100-user limit on unverified external apps. Here is exactly what this means and when it does not apply.
The screen reads: "This app isn't verified. This app has not been verified by Google. It may be requesting access to sensitive information. Learn about the risks." Users must click "Advanced" then "Go to [App Name] (unsafe)" to proceed. Most non-technical users will stop here - this is the real cost of skipping or delaying verification.
When Google OAuth app verification is NOT required
Internal use only
If you set your OAuth consent screen to "Internal" and your app only serves users within your own Google Workspace organization, no verification is required - regardless of which scopes you request. This is the fastest path for internal tooling.
Testing mode (under 100 users)
An unverified external app can have up to 100 test users added via the Google Cloud Console. Those specific users can authorize the app without seeing a hard block - they see the warning but can proceed. Useful for development and private beta with a small team.
Basic scopes only
If your app only requests non-sensitive scopes (openid, email, profile - basic Google Sign-In), no verification is needed even for external users at any scale. Verification is triggered specifically by sensitive and restricted scopes.
Important framing: the intent of the 100-user cap and the warning screen is to protect users while an app is being reviewed. The correct response to hitting the cap is to submit your app for Google OAuth app verification - not to create multiple Google Cloud projects to spread users across them. Google explicitly prohibits that approach and it can result in your developer account being suspended. The compliant path is either to verify your app or to use a platform that already provides a verified OAuth key, such as Unipile.
Google app verification: timeline & cost in 2026
Google app verification is not a single process - it has three distinct tracks depending on which scopes your app requests. Each track has its own timeline and cost. Here is what to expect in 2026.
If your app only uses non-sensitive scopes (basic Google Sign-In), Google may still require brand verification to confirm your app's identity and homepage domain. This is typically a 2-3 business day process with no cost beyond your time.
You will need to verify domain ownership via Google Search Console and ensure your OAuth consent screen accurately describes your app.
Apps requesting sensitive Gmail scopes must go through Google's full security assessment. Google's team reviews your app's data handling practices, privacy policy, and the justification for each scope you request.
Typical turnaround is 2-4 weeks when your submission is complete. Incomplete submissions (missing privacy policy, vague scope justifications, mismatched authorized domains) restart the clock. Google may request a demo or additional documentation during this period.
Apps requesting restricted scopes - primarily https://mail.google.com/ (full IMAP-level access) - must complete a CASA Tier 2 security assessment in addition to Google's own review. CASA (Cloud Application Security Assessment) is an independent security audit conducted by a Google-approved lab.
In 2026 Google offers a self-serve CASA Tier 2 path via approved labs, typically costing $540-$1,000 (lab fees for automated scanning). This is a significant improvement over the legacy track. The older, manually-driven security assessment previously required by Google for the same scope class cost $15,000-$75,000 and took months - that legacy track still applies to some grandfathered apps and enterprise edge cases. When budgeting, confirm with your chosen lab which track applies to your app.
Total timeline including Google's own review after CASA: 4-12+ weeks from first submission to approval.
Cost summary: Google OAuth app verification in 2026
| Verification track | Scope tier | Timeline | Cost |
|---|---|---|---|
| Brand verification | Non-sensitive (openid, email, profile) | 2-3 business days | Free |
| Security assessment | Sensitive (gmail.send, gmail.readonly, gmail.modify) | 2-4 weeks | Free |
| CASA Tier 2 (self-serve, 2026) | Restricted (mail.google.com) | 4-8 weeks | ~$540-$1,000 |
| CASA Tier 2 (legacy manual, pre-2025) | Restricted (mail.google.com) | 8-12+ weeks | $15k-$75k |
Sources: Google OAuth 2.0 Policies (developers.google.com) and Google Cloud - OAuth app verification overview (support.google.com). CASA Tier 2 self-serve pricing is based on approved lab rates as of Q1 2026 and may vary by lab and app scope count. The legacy $15k-$75k track applied to apps that went through Google's previous mandatory security assessment vendor program before the CASA self-serve option became available.
Skip the waitCommon Google OAuth errors you will run into
When you manage your own Google Cloud project, a handful of errors come up repeatedly during development and after going live. Here is a quick reference for the six most common ones.
The redirect URI in your request does not exactly match one registered in Google Cloud Console (protocol, trailing slash, and port all matter).
The user's Google Workspace admin has blocked third-party OAuth apps or restricted the specific scopes your app is requesting.
Your app uses sensitive or restricted scopes but has not completed Google's verification process, so Google blocks consent for new users.
The refresh token has expired or been revoked (user changed password, revoked access, or the token has been idle for 6 months). The user must re-authenticate.
The consent screen is misconfigured in Google Cloud Console: wrong user type (Internal vs External), missing test users, or the app is still in draft state.
A scope string contains a typo, or the corresponding API (e.g. Gmail API) has not been enabled in the Google Cloud Console for your project.
Need the full diagnosis? Each of these errors has a specific fix. See our full guide to common Google OAuth and Gmail API errors and how to fix each one.
When OAuth is handled by Unipile, an independent technical intermediary acting on behalf of each authenticated user, these errors are managed at the API layer. Unipile is already CASA Tier 2 certified, so the verification hurdles are handled once, not once per project.
Weeks of verification.
Use Unipile's key and start now.
Don't lose customers waiting on Google's review. Connect Gmail accounts in 5 minutes with our pre-verified developer credentials.
Google OAuth, Simplified: DIY vs managed - ship now or wait weeks?
If your app needs Gmail access for external users, you face two paths: run your own Google Cloud project through the full google oauth app verification process (6-12 weeks), or build on a platform that already carries a CASA Tier 2 certified OAuth key (1-2 days). Here is how each path plays out - and why they are not mutually exclusive.
The strategic read: the DIY path makes sense long-term if you want full ownership of your OAuth brand and consent screen. The managed path (Unipile) makes sense when you need to ship now, avoid the 100-user cap, or defer the CASA Tier 2 cost. These paths are not mutually exclusive - you can build on Unipile today and run your own certification in parallel, then switch to your own credentials (Bring Your Own Credentials) when your app is verified.
If your use case is Workspace-only (internal tooling, HR automation, no per-user consent), the server-to-server alternative is a service account with Domain-Wide Delegation - see our Gmail service account & DWD guide.
Compliance note: Unipile is an independent technical intermediary, not affiliated with, endorsed by, or sponsored by Google. Unipile's Google OAuth client is CASA Tier 2 certified, enabling your users to authorize Gmail access without seeing an "unverified app" warning. This is not a workaround for Google's security review - the review still applies if you build your own Google Cloud app; Unipile has already passed it for the connections it brokers on your behalf. Users can revoke access at any time via their Google Account permissions page.
Test now on Unipile's certified key, certify in parallel, switch when ready
You do not have to choose between shipping fast and owning your Google credentials. Unipile acts as an independent technical intermediary - its Google OAuth client is already CASA Tier 2 certified - so your users never see the unverified app warning and there is no 100-user cap. Run your own Google app verification in parallel, then switch to your own credentials (Bring Your Own Credentials) at any time. Here is the 3-step journey.
Test on the certified key - ship in minutes
Create a free Unipile account and generate an API key. Use the hosted auth endpoint to generate a one-link URL for each user. Redirect your user to that URL - Unipile's Google OAuth consent screen (already CASA Tier 2 certified) handles the authorization. Your user never sees an "unverified app" warning.
When authorization completes, Unipile sends a webhook to your server with the linked account ID. From that point your app can read, send, and sync Gmail via Unipile's unified API - without creating a single Google Cloud project.
// Step 1: generate a one-link auth URL for your user
const res = await fetch('https://api.unipile.com/api/v1/hosted/accounts', {
method: 'POST',
headers: {
'X-API-KEY': process.env.UNIPILE_API_KEY,
'Content-Type': 'application/json'
},
body: JSON.stringify({
type: 'GOOGLE',
name: 'user-456', // your internal user ID
expiresOn: '2027-01-01',
notify_url: 'https://yourapp.com/webhooks/unipile'
})
});
const { url } = await res.json();
// Redirect the user to `url` - Unipile's certified consent screen handles the rest.Run your own Google OAuth verification in parallel
While your product is live and users are active, start your own Google Cloud project setup and submit your app for google oauth app verification. Follow the 5-step credential setup above. If your app uses restricted scopes, initiate your CASA Tier 2 self-serve assessment via a Google-approved lab.
There is no urgency to this step while you are on Unipile's certified key - your users are not blocked, they see no warning, and there is no user cap. Run the process at the pace that suits your team: typically 2-4 weeks for sensitive scopes, 4-12 weeks if CASA Tier 2 is needed.
For scope selection guidance, see our Gmail API Scopes Guide - choosing minimal scopes can move you from the restricted (CASA-required) track to the sensitive (free review) track, saving time and cost.
Switch to your own credentials (BYOC) - one config change
Once your Google Cloud app is verified and you have your own client_id and client_secret, configure Unipile to use your own OAuth credentials for new account connections. This is the Bring Your Own Credentials (BYOC) model: Unipile continues acting as an independent technical intermediary processing requests on behalf of each authenticated user, now using your verified credentials instead of the shared key.
Existing linked accounts remain active. The switch affects only new authorizations. Your users see your verified app name on the consent screen, replacing the Unipile-branded screen. You chose when to invest in verification - not on day one, when you needed to ship.
Microsoft is different: why Azure doesn't need a CASA-style review
If your application needs to access both Gmail and Outlook, the verification burden is asymmetric. Google OAuth app verification - including a potential CASA Tier 2 audit - applies only to Google. Microsoft Azure's approach to app registration and OAuth consent is architecturally different and does not require an equivalent external security audit.
Any app that requests sensitive or restricted Gmail scopes from external users must pass Google's security assessment. Restricted scopes additionally require CASA Tier 2.
- Unverified app warning shown to users
- Hard 100-user cap until verified
- CASA Tier 2 required for restricted scopes (~$540-$1k self-serve)
- Re-review required when adding new sensitive scopes
- Timeline: 2-12+ weeks depending on scope tier
Azure Active Directory (now Microsoft Entra ID) uses an admin consent model for high-privilege scopes. There is no external CASA-style audit requirement for standard mail access scopes.
- No unverified app warning for standard flows
- No user cap during development
- No mandatory external security audit
- Admin consent required for tenant-wide permissions in enterprise tenants
- Microsoft 365 covers both personal Outlook and enterprise Exchange Online via the same OAuth flow
Practical implication for multi-provider apps: if you are building a product that reads email from both Gmail and Outlook accounts, your Google OAuth app verification timeline governs your launch date - not Microsoft's. This is one of the strongest arguments for using Unipile's unified API: both providers are handled through a single integration, and Unipile's certified key covers Google's CASA Tier 2 requirement out of the box, removing it from your critical path entirely.
For a deep-dive on the Microsoft side of this equation - including Azure app registration, consent flows, and Microsoft Graph API access - see our Microsoft Graph OAuth guide.
How Unipile handles your data
Unipile is an independent technical intermediary. The following three notes explain exactly how data flows, what Unipile stores, and what your responsibilities are as a customer - in the context of Google OAuth and Gmail API access.
What Unipile stores - and what it does not
Unipile does not maintain a parallel archive or independent copy of your users' Gmail data. When your application requests email data via the Unipile API, Unipile retrieves it from Google's servers on behalf of the authenticated user and returns it to your application. Data is scoped strictly to the session of the authenticated user and the permissions they granted during the OAuth flow. Unipile does not retain message content beyond what is necessary to fulfill the API response.
Independent technical intermediary - not a Google partner
Unipile operates as an independent technical intermediary, acting on behalf of each authenticated user who has granted access via the OAuth consent screen. Unipile is not affiliated with, endorsed by, or sponsored by Google. Unipile does not share credentials between users - each linked account uses its own OAuth tokens, scoped to that user's authorization. Your application accesses Gmail data only for users who have explicitly completed the OAuth flow and granted the requested permissions.
Google's rate limits apply - usage decisions are yours
Unipile relays Google's Gmail API rate limits and quota constraints to your application. The Gmail API enforces per-user quotas (e.g. 250 quota units per second per user, 1,000,000,000 quota units per day per project). Unipile surfaces these limits but does not override them. Decisions about request cadence, data volume, and user consent scope remain a customer-side decision. You are responsible for ensuring your application's use of Gmail data complies with Google's API Terms of Service and your users' expectations as disclosed in your privacy policy.
For a complete overview of email API capabilities - including send, read, and sync across Gmail, Outlook, and IMAP - see our Email API guide.
Build with UnipileGoogle OAuth for Developers FAQ
Answers to the most common questions about Google OAuth app verification, Gmail API credentials, and managed OAuth via Unipile.
Your app needs Google OAuth app verification if it is set to External user type on the OAuth consent screen and requests any sensitive or restricted Gmail scopes from users outside your own Google Workspace organization. If your app only requests basic scopes (openid, email, profile) or is set to Internal, no verification is required. Any scope that grants access to a user's mailbox, such as gmail.readonly, gmail.send, gmail.modify, or mail.google.com, is sensitive or restricted and triggers the requirement.
Timeline depends on the scope tier your app uses. Brand verification (non-sensitive scopes): 2-3 business days. Sensitive scope review (gmail.send, gmail.readonly, gmail.modify): typically 2-4 weeks when your submission is complete. CASA Tier 2 + sensitive/restricted scopes (mail.google.com): 4-12+ weeks total. Incomplete submissions, such as missing privacy policy, vague scope justifications, or mismatched authorized domains, restart the clock.
Google's own security assessment (for sensitive scopes like gmail.send and gmail.readonly) is free. Brand verification is also free. If your app uses restricted scopes (mail.google.com), you need a CASA Tier 2 audit by a Google-approved lab. The 2026 self-serve CASA Tier 2 path costs approximately $540 to $1,000 in lab fees. The legacy manually-driven assessment previously required for the same scope class cost $15,000 to $75,000 and that legacy track still applies to some edge cases and grandfathered apps.
You cannot skip Google app verification for a production app serving external users with sensitive Gmail scopes. The 100-user cap and unverified app warning apply until your app is verified. The compliant alternatives are: set your app to Internal (if it only serves your own Workspace users), use Unipile's CASA Tier 2 certified OAuth key while your own verification runs in parallel, or request only non-sensitive scopes that do not trigger verification. Creating multiple Cloud projects to spread users across them is prohibited by Google's policies and can result in account suspension.
See Unipile's managed Gmail API endpoint.The Gmail API unverified app warning appears when your OAuth consent screen is set to External and your app requests sensitive or restricted Gmail scopes but has not yet completed Google's verification process. It is shown to all users outside your 100 test users list. To resolve it: submit your app for Google OAuth app verification via the Google Cloud Console, or build on Unipile's pre-verified, CASA Tier 2 certified OAuth key. Users connecting via Unipile's hosted auth flow never see this warning.
CASA Tier 2 (Cloud Application Security Assessment) is an independent security audit required by Google for apps that request restricted scopes, primarily https://mail.google.com/, which grants full IMAP-level Gmail access. It is conducted by a Google-approved lab. In 2026 a self-serve path is available at approximately $540 to $1,000. You only need CASA Tier 2 if your app requests the mail.google.com scope from external users. If you use only sensitive scopes (gmail.send, gmail.readonly, gmail.modify), CASA Tier 2 is not required. Google's standard free security assessment applies instead.
A Gmail API key is for public, non-user-specific requests and does not grant access to any user's mailbox. Gmail API OAuth credentials (client_id + client_secret) are used to obtain per-user authorization to access their Gmail data on their behalf. For any feature that reads, sends, or modifies a user's email, you need OAuth credentials, not an API key. For a detailed comparison, see our Gmail API Key vs OAuth guide.
Still have questions about Google OAuth app verification or managed Gmail OAuth? Our team is here to help.
Talk to an expert
EN 
FR 
ES 
DE 
IT 
BR 
NL 
PL 
TR