All apps that access Google APIs must verify that they accurately represent their identity and intent as specified by Google's API Services User Data Policy. To protect you and the shared users of Google and your app, your consent screen and application might need verification by Google.
Your app requires verification if it meets all the following criteria:
- In the Google API Console, your app's configuration is set for a user type of External. This means your app is available to any user with a Google Account.
- You want your application to display a logo or display name on the OAuth consent screen.
If you include verified brand information, you can increase the likelihood that a user recognizes your brand and decides to grant access to your app. Verified brand information can also lead to fewer revocations later on when a user or Google Workspace administrator reviews third-party apps and services with access to the account. The OAuth consent screen brand verification process typically takes 2-3 business days after you submit for verification.
If you fail to submit your application for brand verification, it might result in decreased user trust of your request for their data, which can lead to fewer user authorizations and more revocations later.
OAuth consent screen
The consent screen tells users who is requesting access to their data and what kind of data your app needs to access on their behalf, as highlighted in Box 2 of figure 1.
When your app goes through the brand verification process and receives approval, your application's identity and user data policies are more clearly understood by the account that's granting permission. This clear understanding can increase the likelihood an account holder authorizes your requests and maintains access when they review possible revocations on their Google Account page. The content you configure on the OAuth Consent Screen page in the API Console populates the following components:
- Your app name and logo (as shown in Box 1 of figure 1)
- Your user support email, which appears after your app name is selected (Box 2 of figure 1)
As part of the brand verification process, Google requires verification of all domains that are associated with an application's OAuth consent screen and credentials. We ask you to verify the domain component available for registration on a public suffix: the "top private domain." For example, an OAuth consent screen that's configured with an application home page of https://sub.example.com/product asks the account holder to verify ownership of the example.com domain.
Verify the ownership of your authorized domains using Google Search Console. A Google Account with owner permissions for a domain must be associated with the API Console project that uses that authorized domain. For more information about domain verifications in Google Search Console, see Verify your site ownership.
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:
- Confirm that your app doesn't fall under any of the use cases in the Exceptions to verification requirements section.
- 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.
- 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.
Make sure that your home page meets the following requirements:
- Your home page must be publicly accessible, not only 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.
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.
To submit for verification, follow these steps:
- Go to the API Console OAuth Consent Screen page.
- Click the Project selector button.
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:
Replace [PROJECT_ID] with the project ID you want to use.
- Select the Edit App button.
- Enter the necessary information on the OAuth consent screen page, and then select the Save and continue button.
Provide any additional information that's requested about your app in the subsequent steps.
- 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 user 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.
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.
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.
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 by an organization administrator.
- Learn more about public and internal applications.
- Learn how to mark your app as internal in the FAQ How can I mark my app as internal-only?
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.