By Greg Nowak. Last updated 2026-06-26.
Google has set the date: Content API for Shopping will be shut down on August 18, 2026. As of June 26, 2026, that leaves less than eight weeks to find every dependency, clean up weak feed logic, and move production workflows to Merchant API without damaging product visibility.
For ecommerce teams, this is not just a developer ticket. Product feeds usually carry pricing, availability, country targeting, local inventory, promotions, PIM enrichment, ERP data, manual fixes, and agency-maintained scripts. If those pieces are unclear now, a rushed API migration will make the mess harder to see, not easier to operate.
What Merchant API changes in practice
Merchant API is Google’s current programmatic platform for Merchant Center work. It covers products, accounts, inventories, data sources, promotions, reports, return policies, diagnostics, and more. That scope matters because many Content API installations do more than upload products. They also check status, reconcile stock, push supplemental attributes, pull reports, or support internal admin tools.
The product migration guidance points to several changes that affect real systems:
- Submitted data and processed data are separate. Merchant API uses
ProductInputfor submitted writes, while the read-onlyProductresource shows the processed product after Google applies rules, combines sources, and includes status information. - Writes require a data source.
productInputswrite operations need adataSource. That forces the team to decide which system owns the primary feed and which systems are allowed to add supplemental data. - Identifiers change shape. Product IDs move toward REST resource names such as
accounts/{account}/products/{product}, with product keys based on language, feed label, and offer ID. Encoding and lookup logic need attention. - Status workflows need rebuilding. The old
productstatusesservice is removed. Status information is now part of the processedProductresource. - Batch and update behavior changes.
products.custombatchis not available in Merchant API, andproductInputs.patchbehaves differently from older update assumptions. Queues, retries, and out-of-order updates should be tested. - Fields are stricter. Attributes such as title, price, and link now sit inside
productAttributes, and some values that were loose strings are now enums.
| Migration area | Risk if ignored | Practical action |
|---|---|---|
| Data sources | Systems overwrite each other or move offers into the wrong source. | Map primary and supplemental ownership before writing new code. |
| Product IDs | Teams cannot trace failed items across logs, feeds, and Merchant Center. | Standardize offer IDs, feed labels, encoding, and lookup tooling. |
| Status handling | Rejected products are missed until sales or traffic drops. | Rebuild monitoring around processed products and diagnostics. |
| Batch jobs | Large updates fail slowly, retry badly, or apply out of order. | Test batching, concurrency, retries, and version controls under load. |
| Feed cleanup | Old country, inventory, and override rules are copied into the new API. | Clean the feed model before cutover, not after it. |
Why cleanup belongs inside the migration
Older Content API setups often reflect years of small changes. Google’s own release notes show how the feed model evolved, including supplemental Content API feeds, feedLabel, and the deprecation of targetCountry. If your catalog still relies on inherited country assumptions, manual overrides, or unclear local-versus-online rules, the Merchant API move is the moment to fix them.
This is also a business ownership question. Developers can translate endpoints, but operations needs to confirm which system is allowed to change price, availability, title, shipping eligibility, local inventory, promotions, and supplemental attributes. Without that agreement, the new integration can be technically valid and still produce confusing catalog behavior.
A realistic plan before August 18
Start by inventorying every Content API dependency. Include scheduled jobs, stock syncs, supplemental feed scripts, promotions tools, reporting pulls, diagnostics, internal admin buttons, agency scripts, and manual runbooks. The small scripts are often where the risky assumptions live.
Then map each dependency to Merchant API resources and decide whether it should be rebuilt, replaced, or retired. Product writes, processed reads, diagnostics, reports, inventory updates, and promotions should each have a named path and a named owner.
Next, clean the catalog model. Normalize offer IDs, feed labels, language handling, shipping-country logic, inventory fields, enum values, local product handling, and supplemental overrides. If a rule cannot be explained clearly by the people who operate the store, it should not be silently rebuilt.
Finally, stage the cutover. Run the new flow in parallel where possible, compare submitted ProductInput data with processed Product data, review diagnostics, test deletes and updates, and rehearse rollback. Pay close attention to delayed visibility, partial failures, retry loops, and update ordering. Merchant API includes controls such as versionNumber for a reason.
Where Greg can help
This is a good fit for an external digital project manager when the business understands the store but lacks spare integration capacity. Greg can help audit the current feed stack, coordinate developers and agencies, translate Content API usage into Merchant API work, clean up data-source ownership, and keep the rollout tied to operational risk instead of just endpoint parity.
If Content API still sits anywhere in your ecommerce stack, August 18, 2026 should be treated as the stop date, not the project kickoff date.
Related on GrN.dk
- AI Shopping Surfaces Make Product Data Integrity a Technical Ops Job
- Google AI Overviews Liability Turns Brand-Summary Remediation Into a Source-of-Truth Cleanup
- AI Search Visibility Is Now a Measurement Problem After Google's 2026 Guidance Changes
Need help with this kind of work?
Scope your Merchant API migration Get in touch with Greg.
