Guaranteed 100% Facebook, Instagram and WhatsApp Approvals & App Review
Quick Transfer Ready to use app available for Facebook, Instagram and WhatsApp
Guaranteed 100% Facebook, Instagram and WhatsApp Approvals & App Review
Quick Transfer Ready to use app available for Facebook, Instagram and WhatsApp
Gmail API

Restricted Scope Is Not the Finish Line — It Is the Start of a Security Assessment

Most developers discover the CASA Tier 2 requirement at exactly the wrong moment: after the integration is built, after the OAuth app verification has been submitted, and after the team assumed the consent screen was the hardest part. The Gmail API has a category of scopes called Restricted Scopes — eight of them — that trigger a security assessment requirement on top of the standard OAuth app verification process. If your app stores or transmits restricted scope data on a server, Google’s policy requires an annual security assessment by a Google-approved third-party assessor before your app can access that data in production. That assessment is called CASA Tier 2. It is not optional, it is not a formality, and it takes time that most project timelines do not account for.

What Triggers the CASA Tier 2 Requirement

Two conditions must both be true: (1) your app requests at least one Gmail API Restricted Scope — any of the eight scopes in Google’s restricted category — AND (2) your app accesses, stores, or transmits that restricted scope data from or through a server. If your app only uses Sensitive scopes such as gmail.send or gmail.addons.current.message.readonly, CASA Tier 2 does not apply. In practice, nearly every production SaaS integration that reads or modifies Gmail mailboxes at scale uses a server — which means CASA Tier 2 is mandatory for the overwhelming majority of Gmail API production apps.

The Eight Gmail API Restricted Scopes

Scope What It Grants
https://mail.google.com/ Full read, compose, send, and permanent delete access to all email
auth/gmail.readonly View all email messages and settings
auth/gmail.compose Manage drafts and send emails
auth/gmail.insert Insert emails directly into the mailbox
auth/gmail.modify Read, compose, and send — without permanent delete bypass
auth/gmail.metadata View message metadata: labels and headers only, not body content
auth/gmail.settings.basic View, edit, create, or change email settings and filters
auth/gmail.settings.sharing Manage sensitive mail settings — restricted to admin/domain-wide delegation use

CASA Tier 1 (Automated Self-Assessment)

Applies to apps with lower user counts and lower-risk scope usage. Completed via a self-assessment questionnaire and automated scanning tools. Faster — typically a few days to one week. Most large-scale Gmail API integrations that store data server-side do not qualify for Tier 1 and fall into Tier 2.

CASA Tier 2 (Independent Assessor Required)

Applies to apps requesting restricted scopes where data is stored or transmitted server-side. Google assigns a Google-empanelled third-party security assessor who performs a DAST scan on your production app, generates a findings report, issues a Self-Assessment Questionnaire, and — after remediation — issues a Letter of Assessment (LOA). Annual recertification required every 12 months from the LOA date.

What the CASA Tier 2 Process Actually Involves

1
Brand Verification and OAuth Consent Screen SetupBefore CASA begins, your app must complete Brand Verification: ownership of authorized domains via Google Search Console, correct OAuth consent screen branding (app name, support email, home page URL, privacy policy URL). The privacy policy must explicitly describe how your app accesses, uses, stores, and deletes Gmail user data — a generic policy fails this check. Brand verification typically takes 2–3 business days if branding is complete and correct. This step must be completed first; CASA cannot begin without it.
2
Restricted Scope Submission and Assessor AssignmentSubmit your app for restricted scope verification through the Google Cloud Console OAuth Verification Center. Declare all scopes in the Data Access page — scopes are grouped into sensitive or restricted categories to flag additional verification required. Google’s Trust & Safety team reviews the submission and assigns a Google-empanelled security assessor from the App Defense Alliance network. This review and assignment phase typically takes 1–3 weeks. During this time, your app remains in testing mode, limited to 100 test users who must manually accept the unverified app warning screen.
3
DAST Scan, Findings Report, and Self-Assessment QuestionnaireThe assigned assessor performs a Dynamic Application Security Testing (DAST) scan against your live production application — staging or localhost environments are not accepted. They generate a findings report and issue a Self-Assessment Questionnaire covering how you handle Gmail data, how you enforce data deletion on user request, and how your privacy policy describes data practices. All critical and high-severity findings must be remediated before the assessor proceeds to revalidation. This phase takes 1–3 weeks depending on findings volume and your remediation speed.
4
Letter of Assessment (LOA) and Google Final ApprovalAfter remediation is validated by the assessor, they issue a Letter of Assessment. Google reviews the LOA and grants verified restricted scope access. Your app can then accept any Google Account in production without the unverified app warning screen. The LOA approval date is the clock start for annual recertification — 12 months later, the entire assessment process must be repeated to maintain access to restricted scopes.

The Timeline Reality Most Teams Discover Too Late

  • Brand verification: 2–3 business days — only if branding, domain ownership, and privacy policy are already set up correctly; errors in any of these reset the clock
  • Submission review and assessor assignment: 1–3 weeks — Google’s internal queue; no way to expedite
  • DAST scan and SAQ: 1–3 weeks — depends on assessor scheduling and your app’s complexity and surface area
  • Remediation and revalidation: days to weeks — high-severity security findings require real code changes, not policy document updates
  • Google final approval after LOA: additional days
  • Total realistic timeline: 4–8 weeks minimum from submission to production-ready verified status; teams that build Gmail integrations without planning for CASA routinely face 6–8 week launch delays after the submission is filed

Annual Recertification: The Ongoing Requirement Teams Forget

CASA Tier 2 is not a one-time gate. Google’s policy requires recertification every 12 months from your LOA approval date. Approximately 90 days before the deadline, Google emails the Cloud Console project’s Owner and Editor accounts with recertification instructions. If recertification is not completed before the deadline, Google can revoke verified status — returning the app to the unverified state and blocking access for users outside the 100-person test pool. To avoid gaps, keep Owner and Editor roles current on your Cloud Console project and associate the email addresses of team members who need to respond to Google’s annual notices. If your app adds a new restricted scope after the initial assessment, a new or expanded CASA assessment may be required to cover that scope before you can use it in production.

Common Mistakes That Add Weeks to the CASA Process

  • Privacy policy does not describe Gmail data practices specifically — Google’s Limited Use requirements mandate that your privacy policy disclose exactly how you access, use, store, and delete Gmail user data; a generic privacy policy that mentions “user data” without specifying Gmail fails this check and sends the submission back
  • Authorized domain not verified under a project Owner or Editor account — domain verification in Search Console must be completed using a Google Account that has Owner or Editor role on the Cloud Console project; a personal account without a project role does not satisfy this requirement
  • Requesting broader scopes than the app actually uses — declaring the full-access scope (https://mail.google.com/) when the integration only sends emails triggers CASA Tier 2 unnecessarily; gmail.send is Sensitive, not Restricted, and does not require a security assessment; scope minimization review should happen before submission
  • Production app not live when the DAST scan is scheduled — assessors scan the live production environment; if your production app is not deployed and accessible when the assessor schedules the scan, the assessment is delayed until rescheduling
  • High-severity DAST findings not remediated before requesting revalidation — submitting for revalidation before critical and high-severity findings are actually fixed extends the assessment by weeks; assessors will not issue an LOA until all qualifying findings are resolved

For a full guide to the general Google OAuth sensitive and restricted scope verification process — covering the consent screen, demo video, privacy policy requirements, and submission steps — see the Google OAuth Verification Guide. For what the “This App Isn’t Verified” warning means and how to remove it during the testing phase before verification is complete, see Google OAuth “This App Isn’t Verified” warning explained. For Google Workspace apps with additional admin-level and domain-wide delegation verification considerations, see the Google Workspace API Verification Guide.

Google makes all OAuth App Verification, CASA assessment tier assignments, and restricted scope access decisions independently. Timelines cited reflect publicly available Google developer documentation and third-party assessor experience reports and may vary by project. This content is based on official Google Identity and Gmail API documentation and is not an official Google publication. Not affiliated with Google LLC or Alphabet Inc.

Building a Gmail API Integration? Get the CASA Requirement Right From the Start.

Done-for-you Google OAuth verification and CASA Tier 2 preparation support — scope selection review, privacy policy audit, OAuth consent screen setup, demo video guidance, submission preparation, and ongoing verification management so your team is not caught off-guard by the security assessment at launch.