Google Merchant API migration: what your store needs to do before August 2026

Google is retiring the Content API for Shopping on August 18, 2026. The v1beta of its replacement shut down February 28, 2026. Only Merchant API v1 remains. If your feed tools, custom scripts, or third-party integrations still point at the old endpoint, they will fail in August and your products will stop updating in Merchant Center.

This guide covers what changed, who is affected, and exactly what you need to do before the deadline. Skip the background if you already know what the Content API is and go straight to the checklist.

What is changing and why

The Content API for Shopping has been Google's main interface for programmatic Merchant Center management since 2010. It exposed everything through a single endpoint: product feeds, account management, pricing data, performance reports. Over time the monolith became hard to extend, so Google rebuilt it from scratch.

The new Merchant API v1 breaks that monolith into separate sub-APIs, each with its own versioning, authentication scope, and endpoint path. The benefit for Google is cleaner architecture. The cost for you is that nothing maps one-to-one.

The sub-API breakdown

Each sub-API handles a distinct slice of what the old monolith did. Here is what each one covers and when you need it.

• Products API — Upload, update, and delete product listings. The most commonly used sub-API. If you sync a product feed programmatically, this is your first migration target.
• Accounts API — Manage merchant accounts, sub-accounts, and MCA (Multi-Client Account) structures. Agencies managing multiple stores need this.
• Reports API — Pull performance data: impressions, clicks, conversions by product. Replaces the old reports resource in Content API.
• Promotions API — Manage promotional offers attached to products. Previously buried in the Content API, now a dedicated service.
• Notifications API — Subscribe to real-time alerts for account status changes, policy violations, and feed processing updates.

How this affects you

The impact depends on how your store connects to Merchant Center.

Feed management via third-party tools. If you use DataFeedWatch, Channable, or GoDataFeed, check with your vendor. Most major platforms have already migrated or have a firm timeline. Ask them directly: "Are you using Merchant API v1?" If they can't confirm, escalate.

Custom scripts and in-house integrations. This is where most stores get caught. A developer built a sync script two years ago and nobody has touched it since. Search your codebase now. Run: grep -r "content.googleapis.com" . — every match is a migration task.

Compliance monitoring tools. Any tool that reads account status, policy flags, or disapproval reasons through the API needs to migrate to the Notifications and Accounts sub-APIs.

Migration checklist

Work through this in order. Each step builds on the previous one.

1. Inventory every integration — List all systems that touch Merchant Center via API. Include third-party tools, internal scripts, ERP connectors, and monitoring dashboards.
2. Search your codebase for the old endpoint — Run grep -r "content.googleapis.com" across all repositories. Every hit is a migration item.
3. Map old resources to new sub-APIs — Products → Products API, accounts → Accounts API, reports → Reports API, promotions → Promotions API. Use Google's official migration mapping table.
4. Update the base URL — Change content.googleapis.com/content/v2.1/ to merchantapi.googleapis.com/[sub-api]/v1beta/ (note: sub-API paths each have their own prefix).
5. Update OAuth scopes — If your app requests https://www.googleapis.com/auth/content, verify the new sub-APIs accept the same scope or require additional scopes.
6. Rewrite request bodies — Resource names changed. merchantId in path parameters becomes a structured account parent path: accounts/{account}.
7. Update response parsers — Field names and nesting changed. Test each response shape against your parsing logic before switching production traffic.
8. Run integration tests in staging — Use a test Merchant Center account against v1 endpoints. Do not skip this step for production accounts.
9. Confirm with third-party vendors — Get written confirmation that each tool you use has completed its migration. A verbal "we're working on it" is not enough with August approaching.
10. Switch production traffic — Once staging passes, cut over. Monitor error rates for 48 hours after the switch.

Old vs new endpoint: products example

// Old endpoint (Content API — dies August 18, 2026)
GET https://content.googleapis.com/content/v2.1/{merchantId}/products

// New endpoint (Merchant API v1)
GET https://merchantapi.googleapis.com/products/v1beta/accounts/{account}/products

// Old: list product issues
GET https://content.googleapis.com/content/v2.1/{merchantId}/productstatuses

// New: product status is folded into the Products sub-API
GET https://merchantapi.googleapis.com/products/v1beta/accounts/{account}/products/{product}

Tools affected — what to ask your vendors

Most enterprise feed management platforms have issued migration timelines. The question is whether they have completed it or are still planning to. Ask each vendor directly:

• "Which API version are you currently using to sync products — Content API v2.1 or Merchant API v1?"
• "What is your cutover date for full Merchant API v1 compatibility?"
• "Will my account need any action on my end when you migrate?"

If a vendor cannot answer the first question with "Merchant API v1," treat that as a red flag and start planning an alternative. August 18 is a hard deadline.

Common migration mistakes

These are the four errors that show up most often when teams do this migration under time pressure.

• Migrating to v1beta instead of v1. The beta is dead. Only v1 is stable. If you see v1beta in your new endpoint paths, confirm with Google's docs whether that specific sub-API has a GA v1 available.
• Missing the account path format change. The old API used {merchantId} as a flat integer. The new API uses accounts/{account} as a resource name. Requests with the old format will fail with 404.
• Assuming client libraries auto-update. Google's client libraries for Python, Java, and Node.js have separate packages for the Merchant API. Check your dependency imports, not just the HTTP calls.
• Not testing error handling. Error response shapes changed. If your code checks error.errors[0].reason from the Content API response, that path may not exist in Merchant API error responses.