Migrating from Google Content API to Merchant API: Official Tools, Risks, and a Shopify-Focused Path

Google's Content API for Shopping reached its sunset date on 18 August 2026. If your company still owns code that calls shoppingcontent.googleapis.com, the migration is no longer a future maintenance task: requests without an active extension can now fail intermittently with HTTP 410 Gone.

Google already provides strong migration documentation, samples, client libraries and new AI-assisted developer tools. Those should be the starting point. The harder question is what they do not provide: a tested implementation already shaped around the boundaries of a custom Shopify-to-Merchant Center TypeScript integration.

Google defines what Merchant API requires. Your repository still has to prove how the migration works in your application.

First: do you actually own this migration?

The urgent migration requirement applies to custom integrations, scripts and internal tools that call Content API directly. Google explicitly says that merchants using a third-party technology partner to synchronise product data—including Shopify's managed Google & YouTube app—do not need to perform the API migration themselves. The provider owns it.

Start with a source search, dependency inventory and production traffic evidence. A string match is a lead, not proof that a path still runs. Conversely, the absence of a literal URL does not rule out a generated client hidden behind a service wrapper.

The current deadline and failure mode

Google records 18 August 2026 as the Content API sunset date. Progressive degradation began on 1 September 2026: calls without an active extension can intermittently receive 410 responses. Google currently describes full decommissioning as early 2027 and warns that the timing may change with ecosystem progress.

Retrying a 410 may appear to work while degradation is partial, but Google is explicit that retries are not a long-term solution. The correct response is to migrate, or to use the temporary extension process when eligible while the migration is completed. Google's Content API deprecation and sunset notice

Fig. 01 — Inventory before intervention

What Google already provides

It is more accurate to call these first-party resources and developer tools than separate migration products. Together they cover four important layers.

1. 01
   Compatibility and migration guides. Google maps the large structural changes, provides sub-API-specific guidance, and documents the recommended migration sequence.
2. 02
   Reference documentation, quickstarts and official samples. These define current resources, methods, authentication, quotas, errors and supported language clients.
3. 03
   Merchant API Developer Documentation MCP server. An MCP-compatible coding assistant can retrieve relevant context from Google's official documentation, guides and code samples through Google's retrieval service.
4. 04
   Merchant API Agent Skills. The mapi-developer-assistant skill adds workflow guidance, prompt refinement and progressive context loading on top of the documentation MCP service.

Google groups the last two under its API Integration and Code Assist Toolkit. It positions the toolkit for code translation, documentation questions, snippet generation and troubleshooting in AI coding environments. The MCP service retrieves public official material; the coding assistant you choose performs the synthesis and code work.

That makes Google's tooling the best place to ask, “What is the current Merchant API method, field or quota?” It does not mean Google has tested the generated change inside your repository, understood your Shopify normalisation rules, or approved your production cutover.

Fig. 02 — Authority plus implementation

Why this is not an endpoint rename

Merchant API is a redesign composed of versioned sub-APIs. Google says similar features are not guaranteed to be fully backwards compatible. Several changes reach into identifiers, persistence and rollout design—not just HTTP paths.

ProductInput also makes the selected data source operationally important. Google warns about accidental “offer stealing” when a write targets the wrong primary source. Preserve the existing offer ID, choose the data-source strategy deliberately, and keep the returned resource names rather than repeatedly rebuilding them. Google's product migration guide

Where a repository kit adds value

Documentation answers what the platform expects. A migration implementation must also answer how to discover old usage, represent application data, constrain concurrency, classify failures, prove behaviour and reverse a writer switch. That is the narrower job of the Silver Vault Google Merchant API Migration Kit.

The kit is not “better documentation.” It is a reviewed implementation layer for a specific kind of repository.

What is actually inside the kit

Version 0.1.0 is reusable TypeScript source for Node.js 22.12 or later. Its supported path is intentionally smaller than the entire Merchant API surface.

The supplied adapters cover ProductInput, online inventory patches, regional inventory and local inventory with an explicit buyer-owned store-code map. The batch runner retries only retryable, idempotent work and preserves partial results. Typed Merchant errors redact common secret fields recursively before evidence is recorded.

An offline walkthrough takes a synthetic Content API fixture through scanner output, Shopify mapping, money conversion, product and inventory requests, fake Merchant responses, redacted evidence and writer-state checks. At publication, all 43 automated tests and both TypeScript type-check targets pass without Google or Shopify credentials.

Fig. 03 — Prove the pattern offline

What the kit deliberately does not do

This is the important correction to broad claims about “a complete migration.” The kit does not automatically rewrite a buyer repository, store credentials, build OAuth screens, provision service accounts, operate queues, deploy infrastructure, monitor production or provide managed synchronisation. It is not a full Shopify app or Merchant Center dashboard.

Accounts administration, Reports, Promotions, Reviews and other surfaces outside the compatibility matrix remain manual-review or out-of-scope work. Data-source coverage is a primary-source helper, not a complete data-source migration engine. Live registration, writes and cutover verification remain the buyer's responsibility.

Those boundaries are useful. They stop an AI agent from quietly treating a reference layer as a hosted product, or interpreting passing offline tests as proof that a real Merchant Center account is configured correctly.

A combined workflow that keeps authority clear

1. Confirm that the host owns direct Content API calls
2. Connect Google's MCP server or install the Merchant API Agent Skill
3. Run the kit scanner and classify every finding
4. Use Google's current docs to resolve endpoint, auth, quota and field semantics
5. Adapt the kit components to the host's Shopify and credential boundaries
6. Run the offline walkthrough, kit tests and host tests
7. Migrate one functional area after explicit operator approval
8. Collect redacted evidence and keep rollback until the area is accepted

The kit's AI instructions define three layers of authority: Google owns current API truth; the kit supplies reviewed implementation patterns; the buyer's application owns its architecture, credentials and production decisions. If the kit and current Google documentation disagree, Google wins and the integration should be adapted.

Fig. 04 — Keep the return path visible

How to decide between Google alone and Google plus the kit

Use Google's resources alone when you need current answers, have a small or non-TypeScript integration, or prefer to design every migration component in-house. The official tools are also the correct route for API surfaces the kit does not cover.

Consider adding the kit when you own a custom Node.js/TypeScript Shopify integration, need to inventory several legacy surfaces, and want tested starting points for product and inventory mapping, batching, typed errors, offline proof and per-area cutover. The value is reduced implementation uncertainty—not exemption from reviewing or operating the final system.

Source note

Google platform details and tool names in this article were checked against official public documentation on 8 September 2026. Recheck the sunset schedule, Merchant API reference and toolkit setup before implementation because API versions, compatibility and decommissioning dates can change.

Silver Vault Project is independent and is not affiliated with or endorsed by Shopify Inc. or Google LLC. Shopify is a trademark of Shopify Inc. Google and Google Merchant Center are trademarks of Google LLC.