Google rewrote its Merchant Center API help page

Google rewrote its Merchant Center API help page

If a retailer reaches Merchant Center through an ecommerce platform, Google says the platform partner manages the migration to Merchant API and the business does not need to take action. The documentation update reported on 2026-09-28 gives custom integrators a different task: check the current prerequisites, authentication, account verification, and Content API sunset before changing code. The help-page rewrite and the migration boundary answer different questions.

Google renamed the page from “API access to Merchant Center” to “Google Merchant Center API” and rewrote and expanded it. The current page presents Merchant API as the redesign and official successor to Content API for Shopping, adds setup and authentication guidance, and documents API diagnostics.^1,2 Google’s developer guidance separately sets the migration boundary for existing Content API integrations.^3,4

What changed in the Merchant Center API help page?

Google changed the page’s name, structure, and practical detail. The new page presents Merchant API as the successor to Content API for Shopping and adds the setup, access, capability, and diagnostics information a developer needs before making a request.

Search Engine Roundtable reported the rename and rewrite.¹ Google’s current page is the stronger source for what the revised documentation now says. It describes Merchant API as a redesign and official successor to Content API for Shopping, intended for complex Merchant Center setups at scale.²

The revised page says Merchant API can provide programmatic access to shopping data, insights, and capabilities. It also describes multiple data sources for products, promotions, and reviews, product uploads that complement files and autofeed, and parallel individual requests. The page says the interface is available through gRPC or REST, where gRPC is a remote procedure call framework and REST is a web API style.²

Is this only a documentation change, or did the API availability change too?

For a retailer using an ecommerce platform, Google says the platform partner manages the Merchant API migration and no action is required from the business. A custom integration follows a different path: its owner must migrate to Merchant API and check the project, authentication, and extension status. The renamed help page documents that work.

Google’s August 2026 Merchant API updates give the sunset date and migration direction.³ Google’s deprecation guidance adds the operational boundary: requests from clients without an active extension can intermittently return HTTP 410 Gone from September 1, 2026. An HTTP 410 is a server response indicating that the requested resource is no longer available.

The guidance separates three situations:

1. If a business accesses Merchant Center through a third-party ecommerce platform, the platform partner manages the migration on its behalf, and Google says no action is required from the business.
2. A business with a custom Content API integration must migrate to Merchant API as soon as feasible.
3. A project with an approved extension is protected only through the approved extension window. Google says an extension does not continue past final decommissioning in early 2027, and the timing remains subject to revision based on migration progress.⁴

What does the revised help page require before a Merchant API request?

A Merchant API request needs a Merchant Center account with permission to manage products and inventories, a Google Cloud project for API access, and at least one API developer user linked through one-time Developer registration.

Google’s help page names these as prerequisites, not optional preparation steps.² The account is the Merchant Center account the request will query, update, or use for uploads. The Google Cloud project is used to obtain API access. The API developer role links the account and project through Developer registration.

Before a request, record the following:

• the Merchant Center account and the person who has permission to manage products and inventories;
• the Google Cloud project that will provide API access;
• the user who has the API developer role; and
• the one-time Developer registration linking the Merchant Center account to the Google Cloud project.

Google says API developer users on the linked account receive API communications, including mandatory service announcements, developer surveys, and opportunities.² That makes the registration user an operational contact as well as a permission check.

If the work concerns a retail catalog shown through a Google Business Profile, keep the product-data workflow separate from profile representation. The Google Business Profile guidance covers the listing customers see on Search and Maps. Merchant API setup does not replace claiming and verifying that profile.

Which authentication method fits the integration?

Every Merchant API request needs an authorization token. Use OAuth 2.0 for an application that serves other businesses or manages external accounts, and use a service account for an organization’s own application or background automation that does not require human login.

Google’s authentication guide makes the split by use case.⁵ OAuth 2.0 is the documented path when a product acts for other businesses or multiple independent Merchant Center accounts. A service account is the documented path for an organization’s own application and background jobs that should run without a person signing in.

For a first request in Google APIs Explorer, Google’s help page gives a narrower checklist. Select the Google OAuth 2.0 option, sign in to both the Google Account and APIs Explorer, and allow APIs Explorer to manage product listings and accounts.² That flow is a test and exploration path. It is not a reason to copy a human login flow into a production background job.

The authentication choice should follow ownership and runtime, not convenience. A partner application that serves several merchants needs each merchant’s authorization boundary. An internal feed refresh for one organization can use the organization’s service-account path when the account and project permissions are configured for it.

How can I verify Merchant API access before changing code?

Use Google’s account-verification sequence: find the Merchant Center merchantId, build the account resource name, run accounts.products.list in API Explorer with Google OAuth 2.0 and an API key, and treat HTTP 200 as a successful setup check. A new account may return no products and still pass the connection check.

Google’s verification guide gives a repeatable request rather than asking a developer to infer access from the page rename.⁶ The resource name uses the account pattern accounts/{merchantId}. Enter it in the parent field for accounts.products.list, select Google OAuth 2.0 and an API key, and execute the request.

Run the check in this order:

1. Find the Merchant Center account’s merchantId.
2. Construct the parent resource as accounts/ followed by that identifier.
3. Open accounts.products.list in Google APIs Explorer and enter the parent resource.
4. Select Google OAuth 2.0 and API key, complete the permission prompts, and execute the request.
5. Treat HTTP 200 as a successful setup check, then separate an empty product response from an authentication or permission failure.

Google says a newly created account may have no products, so an empty result is not by itself evidence that the connection failed.⁶ After this compatibility check, choose the client-library or service-account flow that matches the application’s ownership and runtime.

What does the Merchant API rewrite change for a Google Maps profile?

The rewrite concerns Merchant Center’s programmatic product, inventory, account, and Shopping API work. It does not replace the separate Business Profile process for adding or claiming a profile, completing verification, and editing the business on Google Search or Maps.

Google’s Business Profile help says a business must add or claim its profile and verify it to show on Search, Maps, and other Google services. It also says owners can edit the profile directly on Search or Maps.⁷ That is a different workflow from Merchant API authorization.

The boundary matters for local retailers. A Merchant API request can manage product or shopping data without becoming a Business Profile claim. Conversely, a current local SEO check should not be marked complete merely because a developer confirmed API access. Profile ownership, business facts, service area, hours, products, and website information may require different checks.

If the question is how to show products or services on a profile, use the documented products and services workflow. If the question is whether a code integration can still update Merchant Center data, use the Merchant API prerequisites, authentication guide, verification request, and sunset guidance together.

What should a business check this week?

First identify whether the business owns a custom Content API integration or uses an ecommerce platform. Then open the current Merchant API documentation, verify access with a test account request, and record the authentication path and migration deadline before changing production code.

The practical check is short:

1. Search code, logs, and the ecommerce platform settings for Content API for Shopping references.
2. If a custom integration exists, map its account, Cloud project, API developer user, authentication method, and active extension status.
3. Run Google’s accounts.products.list verification request against a suitable Merchant Center account.
4. Compare the request methods the integration uses with the current Merchant API documentation.
5. If a third-party platform owns the integration, Google says the platform partner manages the migration and no action is required from the business; any status question is optional follow-up, not a reason to change credentials locally.

Keep the result with the integration record. If a request fails or a migration decision is made, reopen the current Merchant API help, authentication, verification, and sunset guidance before changing production code.

FAQ

Google renamed and expanded the Merchant Center API help page, while its related developer guidance says Content API for Shopping has reached sunset. The safe response is to check the current prerequisites, choose authentication by use case, verify access with a documented request, and keep Merchant Center API work separate from Business Profile management.

Did Google launch a new Merchant API with this help-page rewrite?

No. The report describes a renamed and rewritten help page. Google’s current help page calls Merchant API the redesign and official successor to Content API for Shopping. The related sunset guidance is the API-lifecycle change that requires existing developers to migrate.^1,2,4

Is Content API for Shopping still the primary integration path?

No. Google’s August 2026 updates say Content API for Shopping reached sunset on August 18, 2026 and instruct existing developers to migrate to Merchant API. An approved extension can protect a project only through its approved window.^3,4

What do I need before making a Merchant API request?

You need a Merchant Center account with permission to manage products and inventories, a Google Cloud project for API access, and at least one API developer user connected through one-time Developer registration.²

Should I use OAuth 2.0 or a service account?

Use OAuth 2.0 when an application serves other businesses or multiple external Merchant Center accounts. Use a service account for an organization’s own application or background automation that should run without human login. Every request still needs an authorization token.⁵

Does Merchant API setup verify my Google Maps profile?

No. Merchant API setup checks programmatic access to Merchant Center data. Google separately requires a business to add or claim and verify its Business Profile to show on Search and Maps. The two checks can matter to the same retailer, but one does not replace the other.⁷

Check the current Google documentation again before treating a renamed or expanded help page as a working API contract.