Commerce teams still calling Google’s Content API for Shopping have reached the final stretch. Google says access to the legacy API ends on August 18, 2026, after which it will be shut down. For a business that uses the API directly to send products, update inventory, pull diagnostics or run reporting workflows, this is an operational deadline—not a background platform change.
The replacement is Google’s Merchant API. Google describes it as the primary programmatic interface for Merchant Center and has published migration guidance for teams moving from Content API. The important practical point is that this is not always a simple endpoint swap. Resource identifiers, request formats, batching behavior and some data types change. Any automation that assumes the old API will continue working after August 18 carries a real risk of stale listings, failed updates or blind spots in product operations.
The deadline applies to direct Content API users
Google’s Merchant Center Help documentation says the Content API for Shopping remains available only until August 18, 2026, then will be shut down. The deadline matters most to merchants, agencies and software teams that make direct calls to the Content API or operate a custom integration on a merchant’s behalf.
Not every store owner needs to rewrite software. Google’s migration overview makes a useful distinction: merchants who send product data through a third-party technology partner, such as Shopify’s Google & YouTube app, do not need to perform the API migration themselves because the provider handles it. That is not a reason to assume the store is safe. It is a reason to confirm exactly which system owns each feed, inventory update, promotion, reporting job and error-monitoring workflow.
For teams with a custom app, middleware, ERP connector, feed-management service or agency-maintained scripts, the first question is simple: does any production job still call shoppingcontent.googleapis.com or use a Content API client library? If the answer is yes, treat that dependency as a release-blocking item.
Why a last-minute cutover is risky
Google’s documentation is clear that Merchant API has a different design. Request URLs use a sub-API, version, resource name and method. Merchant API also uses a name resource identifier instead of the older Content API ID conventions, and child-resource operations use a parent field. Google advises implementers to retain the returned name instead of manually constructing it.
Those changes affect more than the transport layer. A product read, a local-inventory update and an account operation can each need revised identifiers and revised request shapes. Google also notes that the legacy customBatch method is not supported in Merchant API; teams should use the documented multiple-request or asynchronous approaches instead. Code that depends on a single large batch response should therefore be tested for concurrency, retry behavior and error aggregation before it is placed back on a production schedule.
Data handling deserves the same attention. In the compatibility guide, Google shows that price amounts move from a string value to an integer amount in micros, while the currency field changes to currencyCode. That sort of difference can produce a dangerous result: a job may succeed technically while sending a wrong value or failing a downstream validation rule. A migration plan should include field-level checks, not just a successful authentication test.
Start with an ownership and dependency map
The fastest responsible response is not to begin replacing code at random. First, make a compact map of every system that touches Merchant Center programmatically. Include the owner, the Google account, the API currently used, the jobs it runs, its schedule and the business consequence if it fails.
Typical entries include a nightly product export, intraday availability updates, supplemental-feed changes, local inventory updates, promotions, disapproval retrieval, order-tracking data and reporting extracts. Add the places that might be easy to miss: scripts on a server, cloud functions, scheduled automation, a warehouse connector, a feed vendor configuration and old agency credentials.
Once that map exists, separate provider-managed connections from direct integrations. A provider-managed connection still deserves a written confirmation from the provider that its Merchant API transition is complete. A direct integration needs an engineering owner and a tested migration path. This classification keeps a lean commerce team from spending time rewriting something a platform partner already operates while ensuring that bespoke dependencies do not disappear into an assumption.
Use Google’s migration sequence, then test the business flow
Google’s migration guidance recommends mapping Content API methods to Merchant API methods, understanding the broader changes and reviewing the relevant sub-API migration guides. In practical terms, start with the live requests that keep a merchant trading: product creation and updates, availability, pricing, data-source management and the diagnostics that tell the team when something has gone wrong.
Merchant API requires the Merchant Center account and Google Cloud project to be linked through developer registration. Google’s quickstart also lists account creation, Cloud project setup, authentication, developer registration and a first product insertion as its core getting-started path. These prerequisites should be completed under the production owner’s account controls, not left to an unrecorded individual credential.
Then prove the result with representative data. Send a controlled product update in a non-production or limited-scope environment where possible. Confirm the returned resource name is stored correctly. Verify the product is visible in the expected Merchant Center data source, inspect any issues, and compare the resulting price, availability, identifiers and destinations against the source system. Finally, observe the next scheduled job and its alerting path. A migration is not finished merely because an API request returned HTTP 200.
A seller checklist for the next six days
- Inventory every integration: Search code, automation logs and vendor configurations for Content API endpoints, libraries, service accounts and jobs.
- Name the owner: Assign a technical owner and a commerce owner for every direct dependency; record an escalation contact for each provider-managed connector.
- Register and authorize deliberately: Confirm the correct Google Cloud project is linked to the primary Merchant Center account before moving production calls.
- Migrate by business risk: Prioritize availability, price and product-update paths, then the diagnostics and reporting that help the team detect failures.
- Test field mappings: Pay particular attention to resource names, parent fields, prices, request URLs and the replacement for custom batching.
- Prove monitoring: Make sure failed requests create an actionable alert and that a human knows where to inspect Merchant Center issues.
- Get provider confirmation: If Shopify, a feed platform or another partner owns the connection, keep confirmation of its migration status with the store’s operational records.
What merchants should not do
Do not assume that a healthy storefront means the integration is healthy. A catalog can look normal today while the automated job that keeps availability or price current is scheduled to stop after the cutoff. Do not treat a third-party app as an automatic exemption without confirming which jobs it owns. And do not replace endpoint strings without checking Google’s resource, identifier and data-model guidance.
The August 18 cutoff is a short, clear deadline. The merchants best positioned for it will leave the transition with something more valuable than a working API: a documented map of the systems that control their product data, a tested recovery path and clear ownership for the next platform change.
Sources: Google Merchant Center Help: Introducing Merchant API; Google for Developers: Migrate from Content API for Shopping to Merchant API; Google for Developers: Start your migration; Google for Developers: Merchant API quickstart.