Sensitive scope verification

If your app asks for permission to use Google APIs to access Google users' data, you might have to complete a verification process before you make your app publicly available for the first time.

Whether this requirement applies to your app depends mostly on two factors:

  1. The type of user data you access—public profile information, calendar entries, files in Drive, certain health and fitness data, etc.
  2. The degree of access you need—read-only, read and write, etc.

When you use OAuth 2.0 to get permission from a Google Account to access their data, you use strings called scopes to specify the type of data you want to access on their behalf. If your app requests scopes categorized as sensitive or restricted, you probably need to complete the verification process unless your app's use qualifies for an exception.

Examples of sensitive scopes include reading events stored in Google Calendar, storing a new contact in Google Contacts, or deleting a YouTube video. For more information about available scopes and their classifications, refer to the reference documentation of the API endpoints called by your app and any related authorization guide published for the API.

You must request scopes that require the least amount of access to user data necessary to provide that functionality. For example, an app that only reads data must not request access to read, write, and delete content when a more narrow scope is available for the API and its related endpoints. Data that you receive from a Google API must only be used in compliance with the policies of the API and in the way that you represent to your users in your app's actions and in your privacy policy.

Be sure to account for the time needed to complete verification into your launch plan for your app or any new features that require a new scope. The sensitive scope verification process typically takes 3-5 business days to complete. Note that your app might be eligible to complete brand verification as a subset of your sensitive scope verification request.

Understand sensitive scopes

Sensitive scopes require review by Google before any Google Account can grant access. Google Workspace organization administrators might restrict access to sensitive scopes to prevent access by OAuth client IDs that the organization doesn't explicitly mark as trusted.

Understand your scope use

  • Review the scopes your app uses or you want to use. To find your existing scope usage, examine your app's source code for any scopes sent with authorization requests.
  • Determine that each requested scope is necessary for your app feature's intended actions and uses the least privilege necessary to provide the feature. A Google API typically has reference documentation on the product's Google Developer page for its endpoints that includes the scope required to call the endpoint or specific properties within. For more information about the necessary scopes of access for the API endpoints that your app calls, read the reference documentation of those endpoints.
  • Data that you receive from a Google API must only be used in compliance with the policies of the API and in the way that you represent to your users in your app's actions and in your privacy policy.
  • Reference the API documentation to learn more about each scope, including its potential sensitive or restricted status.
  • Declare all scopes used by your app in the API Console's OAuth consent screen configuration scopes page. Scopes you specify are grouped into sensitive or restricted categories to highlight any additional verification that's required.
  • Find the best scope that matches the data used by your integration, understand its use, reconfirm that everything still works in a testing environment, and then prepare to submit for verification.
A table displays the name of an API, one of its sensitive scopes, and a description of what the scope covers.
Figure 1. An example of a sensitive scope shown in the OAuth consent screen configuration scopes page.

Steps to prepare for verification

All apps that use Google APIs to request access to data must perform the following steps to complete brand verification:

  1. Confirm that your app doesn't fall under any of the use cases in the Exceptions to verification requirements section.
  2. Ensure that your app complies with the branding requirements of the associated APIs or product. For example, see the branding guidelines for Google Sign-In scopes.
  3. Verify ownership of your project's authorized domains within the Google Search Console. Use a Google Account that's associated with your API Console project as an Owner or an Editor.
  4. Make sure all branding information on the OAuth consent screen, such as the app name, support email, home page URI, privacy policy URI, etc., accurately represents the app's identity.

Application home page requirements

Make sure that your home page meets the following requirements:

  • Your home page must be publicly accessible, and not just accessible to your site's logged-in users.
  • The relevance of your home page to the app that's under review must be clear.
  • Links to your app's listing on the Google Play Store or its Facebook page aren't considered valid application home pages.

Application privacy policy link requirements

Make sure that your app's privacy policy meets the following requirements:

  • The privacy policy must be visible to users, hosted within the same domain as your application's home page, and linked to on the OAuth consent screen of the Google API Console. Note that the home page must include a description of the app's functionality, as well as links to the privacy policy and optional terms of service.
  • The privacy policy must disclose the manner in which your application accesses, uses, stores, or shares Google user data. You must limit your use of Google user data to the practices that your published privacy policy discloses.

How to submit your app for verification

A Google API Console project organizes all of your API Console resources. A project consists of a set of associated Google Accounts that have permission to perform project operations, a set of enabled APIs, and billing, authentication, and monitoring settings for those APIs. For example, a project can contain one or more OAuth clients, configure APIs for use by those clients, and configure an OAuth consent screen that's shown to users before they authorize access to your app.

If any of your OAuth clients aren't ready for production, we suggest that you delete them from the project that's requesting verification. You can do this in the Google API Console.

To submit for verification, follow these steps:

  1. Ensure your app complies with the Google APIs Terms of Service, and the Google API Services User Data Policy.
  2. Keep the owner and editor roles of your project's associated accounts current, as well as your OAuth consent screen's user support email and developer contact information, in your API Console. This ensures that the correct members of your team are notified of any new requirements.
  3. Go to the API Console OAuth Consent Screen page.
  4. Click the Project selector button.

  5. On the Select from dialog that appears, select your project. If you can't find your project but you know your project ID, you can construct a URL in your browser in the following format:

    https://console.developers.google.com/apis/credentials/consent?project=[PROJECT_ID]

    Replace [PROJECT_ID] with the project ID you want to use.

  6. Select the Edit App button.
  7. Enter the necessary information on the OAuth consent screen page, and then select the Save and continue button.
  8. Use the Add or remove scopes button to declare all scopes requested by your app. An initial set of scopes that are necessary for Google Sign-In are pre-filled in the Non-sensitive scopes section. Added scopes are classified as non-sensitive, sensitive, or restricted.
  9. Provide up to three links to any relevant documentation for related features in your app.

  10. Provide any additional information that's requested about your app in the subsequent steps.

    1. Prepare a detailed justification for each requested sensitive scope, as well as an explanation for why a narrower scope isn't sufficient. For example: "My app will use https://www.googleapis.com/auth/calendar to show a user's Google calendar data on the scheduling screen of my app. This lets users manage their schedules through my app and sync the changes with their Google calendar."

    2. Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set its Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.

      1. Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
      2. Show that the OAuth consent screen correctly displays the App Name.
      3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
      4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive scope that you request.
  11. If the app configuration you provide requires verification, you have the opportunity to submit the app for verification. Fill out the required fields and then click Submit to start the verification process.

After you submit your app, Google's Trust & Safety team follows up by email with any additional information they need or steps you must complete. Check your email addresses in the Developer contact information section and the support email of your OAuth consent screen for requests for additional information. You can also view your project's OAuth consent screen page to confirm your project's current review status, including whether the review process is paused while we wait for your response.

Exceptions to verification requirements

If your app is going to be used in any of the scenarios described in the following sections, you don't need to submit it for review.

Personal use

One use case is if you are the only user of your app or if your app is used by only a few users, all of whom are known personally to you. You and your limited number of users might be comfortable with advancing through the unverified app screen and granting your personal accounts access to your app.

Projects used in Development, Testing, or Staging tiers

In order to comply with Google OAuth 2.0 Policies, we recommend that you have different projects for testing and production environments. We recommend that you only submit your app for verification if you want to make your app available to any user with a Google Account. Therefore, if your app is in the development, testing, or staging phases, verification isn't required.

If your app is in the development or testing phases, you can leave the Publishing Status in the default setting of Testing. This setting means that your app is still in development and is only available to users you add to the list of test users. You must manage the list of Google Accounts that are involved in the development or testing of your app.

Warning message that Google hasn't verified an app that's undergoing testing.
Figure 2. Tester warning screen

Service-owned data only

If your app uses a service account to access only its own data, and it doesn't access any user data (linked to a Google Account), then you don't need to submit for verification.

To understand what service accounts are, see Service accounts in Google Cloud's documentation. For instructions on how to use a service account, see Using OAuth 2.0 for server to server applications.

Internal use only

This means the app is used only by people in your Google Workspace or Cloud Identity organization. The project must be owned by the organization, and its OAuth consent screen needs to be configured for an Internal user type. In this case, your app might need approval from an organization administrator. For more information, see Additional considerations for Google Workspace.

Domain-wide installation

If you plan for your app to only target users of a Google Workspace or Cloud Identity organization and always use domain-wide installation, then your app won't require app verification. This is because a domain-wide installation lets a domain administrator grant third-party and internal applications access to your users' data. Organization administrators are the only accounts that can add the app to an allowlist for use within their domains.

Learn how to make your app a Domain-Wide Install in the FAQ My application has users with enterprise accounts from another Google Workspace Domain.