Only show these results:

Google verification and security assessment guide

Google APIs use the OAuth 2.0 protocol for user permissions and consent. If your application accesses Google user data with Google APIs, you might have to take additional steps to comply with Google’s OAuth 2.0 policies and complete the verification process before you publish your application.

In this guide, you’ll learn about the Sign in with Google branding guidelines and Google OAuth verification.

Sign in with Google branding guidelines

To complete the brand verification process, your application must have the "Sign in with Google" button that meets Google's branding guidelines. This applies to the OAuth flow for both personal Gmail (@gmail.com) and Workspace email addresses.

For Hosted authentication in v3, Nylas recommends you do one of the following:

  • Configure the OAuth login prompt by setting the prompt parameter with select_provider or detect,select_provider. For more information, see Configuring the OAuth login prompt.

    ⚠️ Keep in mind: If you add a login_hint that is a personal Gmail or Workspace email address and don't configure a prompt during the Hosted auth flow, the end user is immediately directed to the Google OAuth screen, without clicking the "Sign in with Google" button. This can result in delays or failure in verification.

  • Use the pre-approved "Sign in with Google" button with the “Connect your account” button or other provider login buttons in your application. For more information, see Google's official Sign in with Google branding guidelines.

For Custom auth in v3, use the pre-approved "Sign in with Google" button with the “Connect your account” button or other provider login buttons in your application.

Google OAuth verification

⚠️ Keep in mind: The Google verification and security assessment processes can take several weeks or longer.

If your application accesses Google user data with Google APIs and requests certain scopes, you might have to complete a Google verification process, and a separate security assessment process. Which process or processes depends on whether your app requests sensitive scopes or restricted scopes.

Scope Type Required Processes Google Policy and Requirements
Sensitive Google verification Your application must follow Google’s API Services User Data Policy.
Restricted Both Google verification and security assessment Your application must follow Google’s API Services User Data Policy and meet additional requirements for specific scopes.
  • If your app requests one or more sensitive scopes and doesn't meet any of the criteria for an exception, you need to complete a Google verification process.
  • If your app requests one or more restricted scopes and doesn't meet any of the criteria for an exception, you need to complete both Google verification and security assessment processes. For the security assessment process, Google will assign either Tier 2 or Tier 3 to your app and provide instructions and tools to complete the assessment.

For more information, see Google's OAuth API verification FAQs.

Scopes

The following are the Google scopes that Nylas projects use:

Scope type Scope Nylas API Description Verification Security assessment
Sensitive gmail.send v2, v3 Send messages only. No read or modify privileges on mailbox. Yes No
calendar v2, v3 See, edit, share, and permanently delete all the calendars you can access using Google Calendar. Yes No
calendar.readonly v2, v3 See and download any calendar you can access using your Google Calendar. Yes No
calendar.events v3 See and edit events on all your calendars. Yes No
calendar.events.readonly v3 See events on all your calendars. Yes No
contacts v2, v3 See, edit, download, and permanently delete your contacts. Yes No
contacts.readonly v2, v3 See and download your contacts. Yes No
contacts.other.readonly v3 See and download contacts that are saved in your "Other contacts". Yes No
directory.readonly v3 See and download your organization's Google Workspace directory. Yes No
Restricted gmail.readonly v2, v3 Read all resources and their metadata—no write operations. Yes Yes
gmail.modify v2, v3 Have all read/write operations except immediate, permanent deletion of threads and messages, bypassing Trash. Yes Yes
gmail.compose v2, v3 Create, read, update, and delete drafts. Send messages and drafts. Yes Yes
gmail.metadata v2 Read resources metadata including labels, history records, and email message headers, but not the message body or attachments. Yes Yes

Nylas projects also use the gmail.labels scope, which is neither sensitive or restricted and requires no Google verification or security assessment. The gmail.labels scope enables apps to create, read, update, and delete labels.

Exceptions to verification and security assessment

  • Apps that are not shared with anyone else or that access fewer than 100 Gmail accounts
  • Apps that are set to "Testing" and not "In production"
  • Apps that are configured to work only with internal Google accounts within your organization
  • Apps that have been allowed by Google Workspace admins

For more information, see Google's OAuth API verification FAQs.

Google OAuth verification guide

The Google verification and security assessment processes can be daunting, but our Google OAuth verification guide can help you understand what needs to be done and provide step-by-step instructions on how to do it.