Google has turned a relatively narrow Merchant Center help page into a much broader technical map of its commerce API stack. The page previously titled “API access to Merchant Center” is now presented as “Google Merchant Center API,” with expanded guidance around architecture, setup, authentication, product and account management, developer registration, notifications and newer capabilities around Google’s commerce platform. The rewrite was documented on September 28 after appearing in Google’s official help material.
The change is more significant than a new page title. Google is reframing Merchant API as the primary programmable layer around Merchant Center rather than merely one way to upload product data. Its developer documentation describes the API as a redesign of the Content API for Shopping, organized into modular sub-APIs for account, product, inventory, reporting and other operations.
For retailers, agencies and ecommerce platforms, the practical question is therefore not whether a help page looks different. It is whether existing feed pipelines, authentication models, account-management logic and automated workflows are aligned with the architecture Google is now documenting.
The old page described access; the new guidance describes a platform
Search Engine Roundtable’s comparison says the former “API access to Merchant Center” page contained much less detail about the broader technical architecture and did not include the setup and authentication instructions now surfaced in the rewritten material. The new documentation also calls out benefits and capabilities including Product Studio and direct account notifications.
Google’s developer documentation fills in the architecture behind that positioning. Merchant API is composed of multiple sub-APIs rather than one monolithic surface, and Google says the modular design allows isolated, more frequent feature improvements while bringing the API closer to its standard API design conventions.
This matters for integration teams because a migration should not be approached as a mechanical endpoint substitution. The resource model, setup requirements and operational assumptions have changed.
Merchant API is the redesigned successor to Content API for Shopping
Google explicitly describes Merchant API as a redesign of the Content API for Shopping. It supports automated account management, product management, inventory management and reporting for performance and market insights, while also allowing merchants to manage multiple data sources.
That last point is especially useful for feed architecture. API-managed product data does not have to replace every other ingestion method. Google says Merchant API can update product data alongside other upload methods such as files and autofeed, allowing an integration to complement rather than necessarily replace the rest of the merchant’s data pipeline.
For a retailer that currently treats “the feed” as one file, this is a reason to document the real source-of-truth model before migration. Product attributes may originate in an ecommerce platform, ERP, PIM, warehouse system, scheduled file, supplemental process or API automation. Moving an endpoint without mapping those ownership boundaries can create conflicting updates.
Resource names replace the old mental model of bare IDs
One architectural difference deserves particular attention in code reviews: Merchant API identifies resources using resource names. Google gives a product example such as accounts/123456/products/en~US~sku123, combining the account context and product identity into a structured resource path.
Requests then target the relevant sub-API, version and resource. Google documents the general format as https://merchantapi.googleapis.com/{SUB_API}/{VERSION}/{RESOURCE_NAME}:{METHOD}, with the method suffix omitted for standard operations such as list and get.
Migration tests should therefore cover identifier construction and parsing rather than assuming IDs can be carried over unchanged throughout an existing integration.
Authentication now needs to be chosen by integration type
Google’s current guidance makes a clear distinction between software built for other merchants and software built for the merchant’s own business. Third-party providers and agencies managing external accounts should use OAuth 2.0, while an in-house application operating against its own Merchant Center account can use a service account.
The distinction is not cosmetic. A third-party application needs merchants to grant access through the OAuth consent flow, and Google says apps accessing Merchant API should undergo OAuth verification. Unverified apps can receive warnings and limited functionality; Google says verification typically takes three to five business days.
For internal automation, a service account can support background tasks without a human login. The service account must be created in Google Cloud, its JSON private key must be handled securely and the service-account identity must be added as a user in Merchant Center with the access required for the operations it performs.
Google also makes one prohibition explicit: API keys are not a supported authentication mechanism for Merchant API requests. Attempts to use one for authentication return an unauthenticated error.
Registration is now a first-class setup requirement
Authentication answers who is making a request, but Google separately defines developer registration. Registration is a one-time setup that associates a Google Cloud project with the Merchant Center account and provides Google with the technical contacts responsible for the integration.
The registration flow uses the registerGcp method. Google requires an existing production Merchant Center account, a verified homepage, Admin access for the identity making the registration call, a dedicated Google Cloud project and a valid developer contact email associated with a Google account. Test accounts are not eligible for developer registration.
This is easy to overlook if a team thinks only in terms of OAuth credentials. Registration has a different purpose: Google uses the linked developer contacts for mandatory service announcements, developer surveys and other API communications.
The API Developer role should be part of the access audit
Merchant API also introduces an operational role that integration owners should recognize. Google documents an API_DEVELOPER access right for users who can access Merchant API and its notifications; the role is available only to accounts with developer registration.
When a developer email is registered, Google says an existing Merchant Center user can be granted the API Developer role. If the email is not already attached to the account, a new user can be created and must accept the invitation within 14 days.
For agencies and large retailers, this makes API ownership something that should survive employee turnover. The registered contact, Cloud project ownership, OAuth application and Merchant Center roles should be documented as production infrastructure rather than left attached to an individual developer’s informal setup.
Direct notifications turn Merchant Center into a more event-driven system
The rewritten framing also highlights notifications. Google’s broader Merchant API documentation includes a Notifications sub-API and has continued expanding the events available through it. In May 2026, for example, Google added product-status-change notifications for Universal Commerce Protocol checkout through a dedicated reporting context.
For ecommerce automation, the architectural implication is important. A system does not always need to poll Merchant Center repeatedly to discover that something changed. Where an appropriate notification exists, an event can trigger downstream diagnostics, alerts or remediation workflows.
That can change how feed monitoring is designed. Instead of a nightly job discovering a disapproval hours later, an integration can increasingly treat Merchant Center as a source of operational events and route them into ticketing, monitoring or catalog-repair systems.
Product Studio expands the API story beyond feed transport
Search Engine Roundtable’s before-and-after review notes that the rewritten Merchant Center help page now highlights Google Product Studio among the benefits and exclusive capabilities associated with the modern API story.
That is a meaningful positioning change. Merchant integrations historically centered on structured catalog ingestion: titles, descriptions, prices, availability, identifiers, images and inventory. Product Studio represents a different layer in which Google’s generative tooling can participate in creating or transforming product assets.
Integration owners should therefore inventory not only feed-writing operations but also any workflows that touch creative assets. The Merchant Center API surface is increasingly relevant to both the structured representation of a product and the systems that help prepare how that product is presented.
Google is also building an agentic layer on top of Merchant API
The platform is expanding in another direction that reinforces the importance of a clean migration. Google now offers an experimental Merchant API MCP Access Service in alpha, designed to give LLMs, agents and coding assistants authorized access to Merchant Center data and insights for agentic workflows. Google lists use cases including diagnosing and fixing product disapprovals and generating performance reports.
Google labels the service experimental and says it should not be used for sensitive systems with high reliability requirements.
Still, the direction is clear: the same account, product and reporting architecture used by conventional integrations is becoming the substrate for AI agents. Authentication, authorization and resource hygiene therefore matter beyond today’s feed scripts.
A migration checklist should begin with dependency discovery
Before changing code, teams should identify every system that currently reads from or writes to Merchant Center. That includes ecommerce platforms, PIMs, feed-management services, ERP and inventory systems, custom scripts, scheduled jobs, reporting pipelines, agency tooling and alerting systems.
For each integration, document the account it touches, the product and inventory operations it performs, the credential type it uses, the Cloud project that owns those credentials, its refresh or execution schedule and the system considered authoritative for each field.
This exercise often reveals that “the Merchant Center integration” is actually several integrations with overlapping responsibilities.
Then separate authentication, authorization and registration
Google’s documentation treats these as distinct concepts, and a migration plan should do the same. Authentication verifies the identity making the request. Authorization determines what that identity is allowed to do in the Merchant Center account. Registration connects the Cloud project and technical contacts to the Merchant API program.
Third-party SaaS products should verify their OAuth flow, required scope and app-verification status. In-house automation should audit service-account keys, rotation and Merchant Center access. Both should confirm that developer registration is complete and that the registered contacts are current.
Product feeds need field-level ownership, not just endpoint migration
Because Merchant API can coexist with files and autofeed, teams should define which channel owns each category of data. If the API updates availability while a scheduled file republishes stale availability later, the technical migration may succeed while the business data becomes less reliable.
Inventory is especially sensitive because latency matters. Price and availability should be tested under realistic update volume, including retries, parallel requests and temporary failures. Google explicitly notes that Merchant API supports running multiple individual requests in parallel, which can influence how high-volume update workers are designed.
Third-party ecommerce platforms need a different migration plan
A retailer maintaining its own integration controls its code and credentials. A platform serving thousands of merchants has a different problem: each customer must authorize access, and the application itself must satisfy Google’s OAuth requirements.
Google’s third-party guidance says these applications should use OAuth 2.0 for client-account access rather than service accounts. Each API request must carry a valid authorization token, and the application requests the Merchant API content scope from the merchant through the consent flow.
Platforms should therefore test not only API methods but also merchant onboarding, token refresh, revoked access, partial authorization, account selection and support tooling for reconnecting an integration.
Notifications should be tested as production dependencies
If an automation begins relying on Merchant API notifications, the notification path needs the same reliability discipline as the feed itself. Teams should test event receipt, deduplication, retries, delayed events and what happens when a downstream service is unavailable.
Alerts should also distinguish between an event that merely reports a change and an event that requires human intervention. Otherwise, richer notifications can create more operational noise rather than faster remediation.
Migration is an opportunity to remove legacy assumptions
The most valuable part of Google’s rewritten guide is that it makes the Merchant API architecture harder to mistake for the old Content API with a new name. The modular sub-APIs, resource names, developer registration, explicit authentication models, notifications and newer capabilities are part of a broader redesign.
That makes a one-for-one wrapper around legacy calls a weak long-term strategy. Ecommerce teams should use the migration to identify assumptions inherited from old feed infrastructure: shared credentials, undocumented ownership, polling where events are available, bare IDs embedded throughout code, and integrations whose technical contacts no longer exist.
The documentation rewrite is a signal to audit the entire commerce integration layer
Google’s September 28 documentation change does not by itself introduce a new Merchant API. Much of the underlying architecture already existed in Google’s developer documentation. What changed is the way Google now presents that architecture to Merchant Center users: the API is being described as a central system for programmable commerce operations rather than an ancillary access method.
For retailers and ecommerce platforms, the appropriate response is therefore broader than updating a bookmark. Inventory the integrations, classify their authentication model, complete developer registration, validate resource names and account permissions, define data ownership across API and feed sources, test notifications, and identify where Product Studio or future agentic workflows may touch the same infrastructure.
The endpoint migration is only one part of the work. The larger task is making sure the systems that publish, monitor and automate a merchant’s catalog are built around the Merchant API architecture Google is now documenting explicitly.