Legacy Google+ APIs have been shut down as of March 7, 2019. Changes to the shutdown plan have been made recently which may mitigate its effect on some developers. Learn more.

Google+ integrations for web and mobile apps have also stopped functioning as of March 7, 2019. Learn more.

Google+ Sign-In FAQs

API Project and Cloud Console

Can we reuse an existing API project, or should we create a new project?

There are a few factors to consider to decide whether or not you should create a new project. Specifically, you should consider whether or not the key attributes that are shared at the project level differ for each application. These key attributes are:

  • The product name and logo that appear at the consent dialogue.
  • Access to various APIs.
  • Developer permission management.

You typically do not need to create a new project unless you have special business reasons to keep these attributes separate.

Can we use a single project for several properties/sites, or should we use separate projects for each?

As mentioned in the previous question, Cross-device sign-on works only when all credentials (client IDs) are under the same project. This implies that if multiple properties/sites belong to the same project, then once a user is consented on one property/site, the user is consented on all properties/sites within that project.

To help you best determine what to do, Google's developer policy indicates that you should "put the user first". It may make sense to group properties/sites together in a single project if:

  • All of the sites belong to a common entity/brand.
  • The identity of the requesting entity/brand is clear and apparent.
  • Permissions being granted by users are clearly identified.

For example, BrandX owns SiteA, SiteB, and SiteC. When users visit any BrandX site, users must be made aware of ownership by BrandX, that BrandX is requesting consent for several sites at once, and all of the permissions the user will be granting.

Separate projects are probably necessary if:

  • BrandX is not readily recognized.
  • Permissions across sites are different, making them complex and difficult to clearly communicate.

Another consideration is whether each BrandX site requires its own application. Over-the-air Install handles a single application, so granting OTA consent to multiple applications at the same time is not possible.

How can we request more Quota for a certain API?

From within the Google API Console:

  1. Access your list of enabled APIs in the Google API Console .
  2. From the project drop-down, select the project you created for the API in question.
  3. From the list of Enabled APIs, select the name of the API that requires increased quota. This takes you to a details page.
  4. Select the Quotas tab. This displays a page that shows both the daily quota limit (requests/day) and the per-user rate limit (requests/second/user).
  5. To request more API quota, select the Apply for higher quota link, then fill out and submit the request form. Allow for at least a full business week for your request to be processed.

How do I set up Google+ Sign-In analytics from the console?

Please follow the instructions in Set up Google+ Platform Insights for your app.


What are best practices for integrating our existing native account login process with Google accounts?

The best way to prevent account duplication often depends on:

  • Data elements required by your existing login process.
  • Whether frictionless sign-in or absolute linking is the best experience for your users.

For users who have existing native login credentials and who choose Google+ Sign-In to proceed, you can capture users' e-mail addresses to match to the native account and decide to:

  1. Automatically link the account - if your site uses e-mail as a unique identifier for your users, you can choose to automatically link the account to reduce the friction. However, your login process should inform the user that account linking has occurred.
  2. Let the user decide - if there is any doubt about precise account matching, your login process can use the e-mail match as a signal to prompt users to confirm whether they have an existing account with your site, and if so, to log in (one-time) using the native method. This method insures proper linking of email and Google accounts so in the future, users can log in using only Google+ Sign-In.

In either case, you must consider users who may have previously logged in with a different e-mail address than the one registered with Google. For this reason you should also offer your users the option to manually link their accounts through your site's account profile or settings page. Update your site's help documentation to properly guide them to perform the one-time linking process. This ensures that users can link their existing accounts without accidental duplication.

Some sites opt to always prompt users to link their accounts as part of the initial sign-in, regardless of an e-mail match. Others choose to only prompt users whose e-mails match. Which you choose for your site is ultimately a design choice based on your knowledge of your site's users. You'll need to determine whether it is more important to get new users logged in as quickly as possible, or ensure that as many existing users are linked as soon as possible.

Can I selectively show or hide the sign-in button depending on the user's Google login state?

Yes, a Javascript rendered button can determine a user's login state as described in Monitoring the user's session state. The sign-in callback is automatically invoked as the sign-in button renders. It also returns a few useful attributes:

  • status.google_logged_in - whether or not the user is logged into Google.
  • status.signed_in - whether or not the user is signed into your site.
  • status.method - if signed into your site, whether the user was prompted for

    consent (PROMPT) or automatically signed in (AUTO).

You can use status.google_logged_in state as a signal to promote Google+ Sign-In or to hide the button. However, unless there are compelling reasons to hide the button for some users, we recommend offering the convenience to sign in via Google even to those who have not previously used it.


What are the different scopes available for sign-in?

Please refer to Authorization scopes for a list of scopes you can use with Google+ Sign-In. You must select at least one login scope for sign-in to work. For the majority of integrations, you should choose one of the login scopes and one of the email scopes to proceed. The plus.login scope gives you a user's public Google+ profile information, while profile scope gives you a user's basic information (no Google+ profile required). We recommend that you use email scope since, in majority of cases, the primary e-mail address is what your application needs to match the user. Do not choose multiple login scopes or multiple email scopes as this will employ additional consent verbiage that may confuse your users. Additionally, you can add Google product scopes (for example, Wallet, YouTube, and so on), if they pertain to your application and user experiences. As a best practice in this case, please use our Incremental Authorization capability to prompt users for only the relevant permissions at the appropriate time (that is, when a feature of your application requires an enabled scope in order to proceed).

Offline access refers to your application's request for accesstype="offline" to obtain a refresh token. If you are seeing only this message and no other, it may be due to one of the reasons below:

As part of the OAuth 2.0 flow, you may have enabled this parameter to force the user to always re-consent. When Google introduced incremental authorization, users with this parameter set to force always see the one line consent, but it was not designed for this purpose. The approval_prompt=force parameter should be used only when a user's refresh token is no longer valid and needs to be replaced. This parameter should not be used for any other purpose. If this parameter is set to force while the refresh token is still valid, the one line consent parameter will always appear.

Inconsistent mode between clients
You have requested a refresh token in your web client, but may not have also done so in your Android client. If the user first signs into Android, it will display the one line consent prompt on the next web visit because the user has not yet consented to offline access. Make sure all the scopes and parameters match in different clients so that once the user consents to offline access, all clients can see that consent.

What are best practices for using scopes and invoking incremental authorization?

Scopes are an important decision when designing your application. Google's support for incremental authorization, lets you request scopes that are appropriate for the user's current context. In most scenarios, you'll want to separate absolute functionality from optional functionality. Absolute functionality are core functions your application needs in order to work, while optional functionality are capabilities that users can opt for only when needed.

For example, to provide a frictionless sign-in for users, request the profile information up front. This lets users quickly enter and start using the application without first consenting to a long list of scopes. For example, request Drive API scope only when a user takes an action that requires that scope so the user has to consent only as needed. This approach lets your application support multiple user types and use cases, and keeps authorization relevant to the context of the user's workflow.


What kind of user data can we get from Google Sign-in?

Using the recommended scope plus.login returns the following subset of information categories, which are documented under the People resource of the people.get method:

Base profile information

  • id
  • displayName, familyName, givenName
  • url (profile link)
  • image.url (profile image link)
  • ageRange
  • language


Other useful data elements

  • birthday
  • gender
  • aboutMe
  • relationshipStatus
  • organizations (school, work, etc)
  • placesLived
  • urls (links, other profiles, contributor to, etc)

In addition, people.list returns basic top level profile information about the people within the user's circles.

What data can we keep if the user chooses to disconnect from Google+ Sign-in?

Please refer to the Google+ Platform Developer Policies > Deletion rules for the latest policy.

Where can I find all the Google APIs I can use in addition to Google+ Sign-In?

You can find the complete list of APIs from the Google APIs Explorer. Here is a list of the most popular APIs:

  • Wallet Instant Buy API: Create a seamless checkout process for users.
  • YouTube API: Learn more about users from their interested video categories.
  • Contacts API: Get users' contacts.
  • Calendar API: Learn when users are available and/or add reminders to their calendars.
  • Drive API: Save files and images on behalf of users to their Google Drives.
  • Game Services API: Engage users with gamification by adding leaderboards and achievements to your web/mobile application.

Are there examples of integration best practices Using Google APIs?

Have a look at our ever growing list of Case Studies. If you can't find an example for an API you want to work with, please use the Support channels to let us know.

My API calls are returning HTTP errors (specifically 4xx errors), what do they mean?

Here's a list of common HTTP error codes and messages, with some corresponding troubleshooting tips:

400 - Bad Request or 401 - Unauthorized

  • Check that the access token is correctly supplied in the header of all API requests.
  • Confirm that the access token is still valid (has not expired).

403 - Forbidden

  • Refer to the API's quota in the Google Developer Console to ensure your application is not exceeding the request quota.
  • Ensure Google+ API is enabled in the Developer Console for the application you are testing.
  • Confirm the requested scopes correspond to what is required to invoke the API.
  • Verify that this is not a rare case of requesting a user's circle data while the user is a Google App user who has disabled Google+.

404 - Not Found

  • Be sure the URL is constructed correctly for the API request and all required parameters are included.

A common best practice is to assume incorrect or no data will be returned, and always code to handle such errors gracefully.

Mobile Applications

Can we begin by implementing Google+ Sign-In on a single platform, or must we implement for all platforms that our app supports?

Providing Google+ Sign-In across all platforms delivers a better user experience, especially for users with multiple devices. However, we realize this may not be possible in every case due to resource constraints. If you are unable to integrate Google+ Sign-In across all platforms concurrently, then to ensure an optimal user experience we recommend that you develop a roadmap detailing the timeline for rollout on the other platforms.

If other platforms cannot be implemented within a short timeline, you must consider the use case where a user signs in using Google+ Sign-in on the supported platform, then subsequently tries to sign in using the native account sign-in on an unsupported platform. Here are a few options to ensure that there is no breakage between platforms:

  1. Auto-creation of native account and password - As soon as a user performs Google+ Sign-In, a native account with a random password is also created. The process also sends the user an e-mail confirming creation of the new account. The user can then use the standard password recovery mechanism when attempting a native login on an unsupported platform.
  2. Auto-creation of native account, user creates password - Generally we discourage requiring users to create passwords when signing in with Google. The exception is when users may not be able to sign in on other as yet unsupported platform unless they create a native account password. Creating the native account password lets users provide it if they subsequently sign-in on an unsupported platform.

As soon as the other platforms support Google+ Sign-In, these practices should be removed to provide a truly seamless experience for your users.

When does Cross-platform sign-on trigger for Android?

Follow the requirements in, Cross-platform single sign on (Android) to ensure Cross-platform sign-on works correctly for Android.

Also be sure that:

  • All client IDs on all platforms belong to the same project.
  • The implementation uses the appropriate SDK (GoogleApiClient instead of GoogleAuthUtil).
  • You use the same account to test across platforms.

The immediate sign-in feature works when the application is installed on a device for the first time. When testing this feature you may encounter SIGN_IN_REQUIRED with onConnectionFailed for subsequent installs. At that point, you can either do a reset of the device or clear the Google Play Service cache/data to test immediate sign-in again.

Is Cross-device sign-on available for iOS?

Each iOS device requires users to consent at least once. After that, sign-in takes only a single click.

How do I get a server refresh token on Android?

Please follow the instructions within the Server-side access for your app. Android uses a one-time authorization code to exchange for access and refresh tokens on the server side. Remember that the Client ID required by the request must be the web server's Client ID, not the Android's Client ID.

Over-the-air Installs

OTA is not triggering for us, what could be wrong?

Successfully triggering OTA requires the following:

  1. The web application's Client ID must belong to the same project as the Android app's Client ID.
  2. The Play store and service must be installed and available on the user's Android device.
  3. The app must meet OTA app requirements.
  4. The user must be signing in for the first time, the sign-in must include one of the login scopes, and apppackagename must be specified.
  5. The user must have an active Android device that is compatible with the Android app specified for OTA.
  6. The app must not already exist on the Android device.

After meeting the above requirements you can refresh and test OTA using the instructions, Testing Android app installs for your web site.

If you have setup apppackagename correctly, the consent dialogue's URL will contain the query parameter after_redirect=keep_open. If you don't see that parameter, verify that page-level configuration options aren't conflicting with your sign-in parameters.

No, OTA installation triggers only at the initial consent, which provides a more consistent user experience.

Can I trigger OTA for multiple or different apps?

No, only one Android app download can trigger Over-the-air install. If you require multiple or different apps, please describe your use case or business need through one of Google's support channels.

Can I track engagement for users who install my app via OTA?

There is currently no automatic way to do this. If this is an important feature for you, please tell about your use case or business need through one of Google's support channels.

Interactive Posts

When and why are Interactive Posts useful?

Interactive Posts are extremely useful when you want users to promote activity to their social circles to help drive traffic and engagement back to your site. For instance, if your site is a commerce site, Interactive Posts provide users with opportunities to share a great deal about your site with their friends. Specifically, you can provide a 'Buy' call-to-action button that takes the user's friend directly to a checkout page with the product pre-populated. The social experience can propagate further after the purchase by giving the friend the opportunity to thank the original sender by sending them a coupon, or by sharing the same deal with their own social circles.

Additionally, mobile shares support deep linking, letting you to drive traffic directly into your mobile app. This gives your users a more immersive experience.

For a real-world case study of Interactive Posts in action, check out The Google+ Developers Blog, which details Fancy's implementation.


How do I migrate from a legacy Google login to Google+ Sign-In?

Refere to the Migrating to Google+ Sign-In documentation for migration details for various legacy login methods.

How can I tell which login method we are currently using?

The URL for the user's consent prompt provides key information on the current login implementation.


The URL is composed of the following key characteristics:

METHOD openid2: The OpenID 2.0 login method is deprecated and should be migrated.
oauth2: The OAuth 2.0 login method is deprecated and should be migrated.
Examine other parts of the URL below for additional details.
CLIENT_ID The client ID that identifies the user's consent to your app or site.
REDIRECT_URI If a URL is present you are using the web redirect approach. To take full advantage of Google+ Sign-In features, consider using the JS widget approach. With the JS approach, the value of redirect_uri should be postmessage.
SCOPES The list of scopes that your app or site is requesting. Compare the list to the migration documentation to decide whether you should migrate any of the scopes.

Possibly. It depend upon the method you are moving from and to. Refer to the migration documentation to determine whether or not user re-consent will be needed.


We're seeing "Error: origin_mismatch" during sign-in testing; what might be the issue?

This issue is related to the Authorized JavaScript origins field settings for the Client ID.

To resolve:

  1. Access your list of credentials in the Google API Console .
  2. From the project drop-down, select your project .
  3. On the Credentials page, look for the list of OAuth 2.0 client IDs, and select the web application client ID. This takes you to a details page.
  4. In the Restrictions section, the Authorized JavaScript origins field(s) should contain the appropriate protocol, host name, and port information where the JavaScript is authorized to postmessage.

We're seeing "Error: redirect_uri_mismatch" during sign-in testing; what might be the issue?

This error indicates that you are using the web redirect flow instead of the recommended flow with JS widget support. The web redirect flow does not take advantage of many features such as Cross-Device Sign-On, Over-the-Air Install, and so on.

This issue is related to the Authorized Redirect URI field settings for the Client ID.

To resolve:

  1. Access your list of credentials in the Google API Console .
  2. From the project drop-down, select your project .
  3. On the Credentials page, look for the list of OAuth 2.0 client IDs, and select the web application client ID. This takes you to a details page.
  4. In the Restrictions section, the Authorized Redirect URI field(s) should contain the appropriate protocol, host name, port, and path information that will receive the redirected flow.

What web browsers does Google+ Sign-In support?

Google+ Sign-In supports the same web browsers as the Google+ web interface.

On the OAuth consent screen tab in the Google API Console, you have some control over what is displayed by the consent dialogue (for example, product name, URL, logo, and so on). The consent languages, however, are standardized to ensure a consistent user experience and proper internationalization, so they cannot be modified.

To set the OAuth consent screen content:

  1. Access the OAuth consent screen tab in the Credentials section of the Google API Console .
  2. From the project drop-down, select your project .
  3. On the OAuth consent screen tab, fill out the appropriate fields.
  4. Press Save.

Use the same approach you used to internationalize the sign-in button. Specify the correct language using this technique and the consent dialogue is displayed in the language you choose.

Send feedback about...

Google+ Platform
Google+ Platform