Google's August 18, 2026 Content API cutoff turns feed cleanup into a Merchant API migration project

Google has put a date on a piece of integration work many ecommerce teams would otherwise keep postponing. In its Merchant Center help documentation, Google says Content API for Shopping will remain available until August 18, 2026, and then it will be shut down. If Content API still sits inside your product sync jobs, supplemental feed scripts, status checks, local inventory tooling, or custom catalog middleware, that date changes the conversation. This is no longer a background maintenance task. It is a migration project with operational risk attached.

The important point is not just that one API is ending and another exists. Google positions Merchant API as the replacement platform for programmatic access to Merchant Center, and the documented scope is broader than product insertion alone. The Merchant API documentation covers merchant accounts, products, return policies, data sources, inventories, local feeds partnership, promotions, reports, conversion sources, programs, batch requests, and API diagnostics. That matters for scoping. If your current setup does more than upload products, your migration probably does too.

Why this is not a simple endpoint swap

The products compatibility guide is where the real work shows up. Merchant API changes several behaviors that stable production scripts often depend on, even when the old integration looks straightforward on paper.

Writes and reads are split across different resources. Merchant API uses ProductInput to insert, update, and delete submitted product data. The read-only Product resource is the final processed product after Google applies rules, combines supplemental sources, and attaches product status information.
Every product write must name a data source. Merchant API requires a dataSource query parameter for productInputs write methods. Google also frames uploads around either a primary or supplemental data source. If several jobs feed the same catalog, you need a clear map of which system writes to which source.
Product identifiers changed shape. The old id becomes a REST resource name in the format accounts/{account}/products/{product}. The product portion uses contentLanguage~feedLabel~offerId, and Google says unpadded base64url encoding is required when names contain reserved characters. That usually means changes to identifier logic, logging, and lookup tools.
Status lookups moved. The productstatuses service is removed. Status data now lives inside the processed Product resource, in productStatus. Any tooling that queried a separate status endpoint needs to be redesigned.
Update semantics changed. Google describes productInputs.patch as persistent and significantly different from the old behavior. Teams should re-check overwrite assumptions and conflict handling rather than carrying old patch logic forward unchanged.
Batching is different. products.custombatch is not available in Merchant API. Google points developers to asynchronous requests or HTTP batching instead. If your throughput depends on legacy batch patterns, queueing and retry design need fresh attention.
Field models changed. Product attributes such as title, price, and link are no longer top-level fields; they now live inside productAttributes. The guide also notes that some fields that used to accept strings are now enums, which matters for permissive serializers and validation code.
Some legacy concepts moved or disappeared. The channel field is no longer present. For products that were LOCAL in Content API for Shopping, Google says to use legacy_local instead.

None of that is cosmetic. These differences affect payload builders, serializers, read-after-write checks, alerting, reconciliation jobs, and the basic question of which system is actually the source of truth for a product record.

Why feed cleanup belongs inside the migration

Catalog cleanup and API migration belong in the same workstream because older Content API setups often carry years of accumulated assumptions. The Content API release notes make that clear. Google added support for supplemental Content API feeds in June 2019. In August 2022, it added feedLabel for products, allowed offer IDs to be constructed with feedLabel, and deprecated targetCountry. Google also warned that backfilled targetCountry values based on feedLabel do not by themselves enable offers to serve in that country, and that shipping settings should be used to specify target countries. If your catalog has grown through shortcuts, inherited country assumptions, or layers of supplemental overrides, this is a good moment to clean that up instead of recreating the same mess in a new API model.

The same release notes also document runtime behavior that may still be baked into custom tooling. Google notes that product insert responses contain only a limited set of attributes, that nonfatal warnings and errors are no longer returned in the response, and that there can be a delay of a few minutes before an inserted product is retrievable via get or list. Those details matter more than they sound. Plenty of internal tools quietly assume immediate read-after-write consistency, or expect response payloads to be richer than they really are. A migration is the right time to surface those assumptions and replace them with proper diagnostics and reconciliation.

There is another practical reason to combine cleanup with migration: Merchant API makes data source boundaries explicit. Once every write has to specify a primary or supplemental source, ownership stops being fuzzy. That tends to expose whether ERP exports, PIM enrichments, marketplace rules, local inventory feeds, and manual fixes are coordinated deliberately or simply colliding inside the same product record.

A practical migration plan before August 18, 2026

Google's Merchant API latest updates page shows that the replacement platform is still evolving, which is exactly why this should be run as a scoped project rather than an ad hoc rewrite. Merchant API v1 became generally available in July 2025. Google introduced an upgraded API diagnostics tool in November 2025 to support migration to Merchant API v1. In January 2026, it added ErrorInfo support and published error-handling guidance. Separately, Google had already discontinued Merchant API v1beta on February 28, 2026. The takeaway is straightforward: build against the current stable shape of Merchant API, not older prototypes, outdated samples, or half-migrated internal code.

Inventory every Content API dependency. List scheduled jobs, webhook consumers, admin tools, monitoring checks, feed processors, local inventory updates, promotions flows, reporting pulls, and any manual runbooks that still rely on Content API behavior.
Map calls to Merchant API resources, not just endpoints. Product writes map to ProductInput, processed reads map to Product, status logic moves into productStatus, and batch-heavy workflows may need asynchronous requests or HTTP batching.
Normalize catalog data before cutover. Clean up identifier rules, feedLabel usage, shipping-country assumptions, local-versus-online handling, enum values, and the move from top-level attributes into productAttributes.
Rebuild observability around the new model. Use Merchant API diagnostics, structured error handling, and explicit reconciliation between submitted ProductInput data and the final processed Product. This is where silent failures stop staying silent.
Stage the transition with rollback paths. Run the new flow in parallel, compare outputs, test retry behavior, and check out-of-order update risks. Merchant API's optional versionNumber exists for a reason: ordering problems are common enough to justify a built-in control.

This is the kind of project where integration work and ecommerce operations meet in the middle. Greg can help audit the existing feed stack, map Content API calls to Merchant API resources, clean up product data, tighten authentication and retry logic, and stage the cutover with logging and rollback paths so catalog, stock, and diagnostics do not fail silently.

The main mistake now is to treat the deadline as something to worry about later. Google has already published the stop date. The sensible move is to scope the migration while there is still enough time to test the new model under production-like conditions, compare outputs, and fix edge cases before product visibility or revenue is on the line.

Need help with this kind of work?

Scope your Merchant API migration Get in touch with Greg.

Sources

Last modified

2026-05-21