OAuth setup

Complete the following steps to configure your platform for the OAuth 2.0 implementation:

  1. Configure the merchant consent dialog.

    When a merchant first attempts to access their Business Profile account through the partner platform with use of the APIs, they're presented with the merchant consent dialog.

    Merchant consent dialog
    Access request.

    Once you grant third-party access to your account, Google sends a mandatory email notification to you. The notification alerts you, the location owner, that a change to who may access your account data has been made.

    Your Google Account now displays apps with access to your account, with additional details on what data in particular is accessible by the third-party app. Also, you can remove an app's access at any time when you click the Remove Access button. In this way, you control third-party access to your account data.

    Who has access

    The merchant consent dialog, which is accessible in your Google Cloud Project, allows you to configure the following consent information about the third-party partners to whom you've given access to your account:

    1. Application homepage link: The homepage of the third-party partner to whom you've granted access to your account.
    2. Application privacy policy link: A link to the partner's privacy policy.
    3. Application Terms of Service (ToS) link: A link to the partner's ToS.
    Consent configuration

    For more on consent configuration, see Setting up OAuth 2.0 > User consent.

  2. Set your application name and logo.

    Resellers must have the same application name and logo as our partners, or a separate Google Cloud Project to distinguish them from the Partner default.

    App name and logo setup

OAuth usage by platforms

Platforms may act on behalf of the owners and managers. This minimizes the number of required merchant actions and reduces drop-off rates.

Owners and managers must first sign into the partner platform with their Google Account and have their credentials cached. Cached OAuth 2.0 credentials, access tokens, and refresh tokens are used to view or edit location data.

The following are common examples of OAuth usage by platforms:

  • Create locations as the merchant, which establishes the merchant's Google Account as the primary owner.
  • Partners are able to reply to reviews and create posts as the business owner through a platform API integration.
  • Managers can reply as the business owner when they use the APIs.
  • Merchants can automatically transfer locations into Business Profile organizations.
  • Automatically Add an admin to an account or location, such as a manager.

    For example, an invitation to a management user's Google Account is created by use of your cached OAuth 2.0 credentials. Then, the invitation is accepted with the use of the management user's cached OAuth credentials.

Exceptions that require direct merchant action

Not all actions can be automated by API calls that use the merchant's OAuth credentials.

The following are some examples of exceptions that require direct merchant action:

  • Merchants must sign in to their Google Accounts at least once for the platform to cache OAuth credentials that are later used to make API calls and perform actions as the merchant.
  • Merchants must make a one-time acknowledgement of the OAuth 2.0 consent dialog that grants third party access to location data.
  • Merchants must sign in to their Google Account and manually click a link both to initiate and complete ownership claims.