Merchant API design

We designed Merchant API to be familiar to Content API for Shopping developers, yet simpler and more flexible. Here's some detailed information on the design of Merchant API.

Sub-APIs

Merchant API is a collection of sub-APIs. The sub-APIs are groups of related services and resources. This design means you can choose to use only the sub-APIs needed for your unique integration.

Merchant API includes the following sub-APIs:

  • Accounts: Manage Merchant Center accounts at scale.
  • Conversions: Manage conversion sources for your account.
  • Data sources: View and manage the data sources for your products.
  • Issue resolution: Obtain issues impacting your account and create an in-app diagnostics page.
  • Inventories: Showcase your products by store or region on Google.
  • Local feeds partnership: Upload your local product inventory feed.
  • Notifications: Manage notification subscriptions.
  • Order tracking: Provide historical order tracking data to improve shipping estimates and enhance listings with shipping annotations.
  • Products: Manage product data, like price and availability.
  • Product Studio: Use Google Product Studio to generate product images and text suggestions automatically.
  • Promotions: Create and manage promotions to showcase special offers for your products.
  • Quota: Check the API quota of your accounts.
  • Reports: View data on your products, performance, and competitive landscape across Google.
  • Reviews: Manage product and seller reviews.

Transport

Merchant API's default transport mechanism is gRPC. You can also use REST.

See the quickstart guide for more information.

Enums

Enum fields across Merchant API might be exposing new values in the future. Your code should be structured in such a way that it can handle unrecognized values gracefully. You should monitor the occurrence of unrecognized enum values and intervene to keep the code up to date.

Versioning

Sub-APIs are versioned separately. This means you don't need to do anything if we update a sub-API that you don't use. You only need to update your code when new versions of the sub-APIs you use are released. For more information, see Versioning.

Versions that end in "beta" are subject to change or removal.