Overview

To effectively use Merchant API, it's important to understand the concepts of registration, authentication, and authorization. They serve distinct purposes in ensuring secure and correct access to Merchant Center data.

Terminology

Registration, authentication and authorization are related, but each has a distinct meaning and purpose.

  • Authentication: In this process the service verifies the identity of the user or application making an API request. Merchant API uses standard Google mechanisms like OAuth 2.0. For more information, see Authenticate requests and Authenticate as your own account.
  • Authorization: This process determines what actions the authenticated user or application is permitted to perform using a Merchant Center account. It answers the question: "What can you do?" based on the roles and permissions granted to the authenticated user within the Merchant Center account. For example, a user might be authorized to read product data, but not to modify account settings.
  • Registration: With respect to Merchant API, this is a one-time setup process that lets Google send you important service announcements for the merchant accounts you manage. Registration adds your developer email addresses to your main Merchant Center account and links it to the Google Cloud Project ID(s) you use for authentication. This linkage lets your application, receive service announcements for all the merchant accounts you manage. For more information, see Create a Google Cloud Project.

Registration

The registration process is crucial for enabling your application to use the Merchant API. Here's what you need to know:

Prerequisites

Registering to use Merchant API requires the following:

  • Merchant Center Account: You need an existing Merchant Center account.
  • Admin Access: The Google user account you use to initiate the registration call must have Admin privileges on the Merchant Center account you are registering.
  • Google Cloud Project: Your application must be associated with a Google Cloud Project. This project provides the necessary credentials (like OAuth 2.0 Client IDs) for your application to authenticate.

Why you can't register a shared Google Cloud project

Tools like the Google OAuth Playground and APIs Explorer use shared, Google-owned Google Cloud projects. You cannot register with shared projects because:

  • They are meant for testing and exploration, not for production application identity.
  • Registering them would imply a link between the shared tool and your specific Merchant Center data and may result in unwanted communication.

Your application needs its own dedicated Google Cloud project so the Merchant API communications Google sends to you remain relevant for your actual usage.

Nevertheless, you can use the OAuth Playground and API Explorer webapps to use the Merchant API for experimentation and non-production use cases.

Find your Google Cloud Project ID

You can find your Project ID and Project Number in the Google Cloud Console. For details, see Find the project name, number, and ID.

Make the registration call

Register using the registerGcp method within the Accounts sub-API. This call associates your Google Cloud Project Number with the Merchant Center account.

During the process, you should provide an email address associated with an individual user that you use to call the API. This email must belong to a user with Admin access to the Merchant Center account.

About the email field

Effective communication is key. Google sends important updates, Mandatory Service Announcements (MSAs), developer surveys, and other opportunities related to the Merchant API. Proper contact management ensures that these reach the right people.

  • Purpose: Google uses this email address as a primary contact for API-related communications.
  • Whose email: This should be the email address of an individual developer or a key technical contact who is responsible for the API integration.
  • Best Practices:
    • DO: Use an individual's corporate email address.
    • DO NOT: Use general group aliases or service account emails. We intend communications for human recipients.

The users resource for contact management

While the email address in the registration call sets an initial contact, the more robust way to manage contacts and permissions is using the Merchant API accounts.users resource or the user management settings in the Merchant Center UI. For more information on using Merchant Center, see Manage people on your account.

Take advantage of these features as follows:

  1. Add all developers: Add developers working on the API integration as users of the Merchant Center account.
  2. Assign the API_DEVELOPER role: Besides standard roles (Admin, Standard), you can assign users the API_DEVELOPER role. In particular, assign this role to users who should receive API-related communications. You can combine it with other roles.
  3. Benefits:
    • Clear separation: Decouples API contact management from the one-time registration.
    • Flexibility: Update contacts as team members change.
    • Targeted communication: Ensures API-specific news goes to the relevant people.

Even if you provided an email address during registration, we strongly recommend managing API contacts by adding users with the API_DEVELOPER role.

References

For more information, see the following:

Previous
Migrate from v1beta to v1
Next
Access client accounts