Content API to Merchant API: Your Migration Checklist

What Actually Shuts Off on August 18, 2026

Google is retiring the Content API for Shopping, the interface that has pushed product data into Merchant Center for more than a decade. It keeps answering requests until August 18, 2026. After that, it does not.

“Breaks” here means what it sounds like. Your sync job starts failing. Product data stops updating, so prices and stock levels drift away from reality. Merchant Center eventually stops trusting stale items, listings drop out of Shopping, and Performance Max campaigns lose the inventory they were bidding on. There is no read-only grace period to fall back to.

One deadline has already passed: merchants who built against the Merchant API v1beta had to move to v1 by February 28, 2026. If you are still on v1beta, that is the more urgent problem.

The good news is that a lot of merchants are not affected at all. The sunset applies to programmatic integrations. If your products reach Merchant Center by scheduled fetch, manual file upload, or a Google Sheet, nothing changes for you. What is worth checking is whether something you installed calls the API on your behalf. Plenty of ecommerce platforms, feed apps, and agency-built connectors do, quietly, and the merchant only finds out when the sync dies.

The Data Shape Changed, Not Just the Endpoint

The most common way this migration goes wrong is treating it as a URL swap. It is not. Google rebuilt the API as a set of modular sub-APIs (products, accounts, data sources, reports) and reworked how a product is represented on the way through.

The differences you will actually hit in code:

• Product attributes now live inside a nested productAttributes object instead of sitting flat on the product.
• Prices use amountMicros, an integer where the real value is micros divided by 1,000,000, plus a separate currency code. A price of 19.99 becomes 19990000.
• The single gtin field is now a gtins array, so a product can carry more than one identifier.
• Enum values are normalized to uppercase: IN_STOCK, NEW, MALE.
• Feeds are managed through a Data Sources sub-API with typed feeds rather than the old datafeeds calls.
• Conversational attributes are first-class product fields, which they never were before.

None of those individually is hard. Together they mean your product-mapping layer needs rewriting rather than repointing, and any code that parses a price string or reads a single GTIN needs a second look.

The Content API to Merchant API Migration Checklist

1. Find everything that calls the API

Start with an inventory, because it is almost always longer than expected. The scheduled product sync, obviously. Then the inventory updater that runs every fifteen minutes, the promotions job, the internal dashboard that reads account status, the one script a contractor wrote in 2021 that nobody has opened since. Search your codebase for shoppingcontent and content/v2.1 and see what comes back.

2. Decide what you own and what you don’t

Split the list into integrations you control and integrations a vendor controls. For the vendor side, your job is to get a written answer on their migration status and date, not to fix it. Ask early. A feed app that migrates on August 15 is a real risk to your Q3.

3. Map the fields before writing code

Take your existing product payload and write the Merchant API equivalent next to it, field by field. Prices, identifiers, availability, condition, and any custom attributes are where the surprises live. Doing this on paper first is much faster than discovering the nesting rules through failed requests.

4. Rebuild against the sub-APIs

The modular structure means product writes, account reads, and data source management are now separate services with their own methods. Code that assumed one client for everything needs restructuring. Set up the new credentials and scopes early, since access issues surface late and cost a day each time.

5. Run both in parallel

Do not cut over on a Friday. Point the new integration at the same account and compare what lands: item counts, prices, availability, and per-product status. Let the old path keep running while you verify. You have until August, so use the runway rather than shipping into it.

6. Check status with the API, not by eye

The Merchant API gives you Google’s own verdict on each product, including approval state and the exact reasons for a disapproval. Read it after cutover. If your mapping quietly dropped a required attribute, this is where it shows up, and it beats noticing a week later when traffic falls. If items do come back disapproved, the usual Merchant Center suspects are still the usual suspects.

7. Don’t ship a like-for-like port

More on this below, because it is the part most teams get wrong.

The Mistake That Costs More Than the Migration

A straight port passes every test you write for it. Same products in, same products out, no errors. It also leaves you exactly where you were, on an API that was designed to carry considerably more.

The Merchant API is Google’s AI-ready pipe. The old one moved product data so Google could list it. The new one is built so Google’s AI can understand a product well enough to answer a question about it. That capacity shows up as the conversational attributes: product highlights, structured product details, question and answer pairs, variant options, item group titles, related products, document links, and popularity rank.

They are optional. They do not affect product approval and will not fix a disapproval. That is precisely why they get skipped, and precisely why filling them is worth something while most catalogs ship them blank.

Migrating without the AI fields is like rewiring a house for fibre and then only plugging in the landline.

The practical argument is timing. You are already opening the integration, already re-mapping fields, already testing. Adding the AI fields later means a second project with its own approval cycle. Adding them now is marginal work on a project that is already budgeted.

Where a Supplemental Feed Fits

You do not have to author conversational attributes through the API to get them. For most merchants, the simpler route is a supplemental feed that merges onto the primary feed inside Merchant Center, matched by product id. The primary feed keeps owning price, availability, and identifiers. The supplemental layer adds highlights, details, Q&A, and variant options on top.

That separation is useful during a migration. Your API work stays focused on the data that has to be right, and the enrichment layer sits alongside it without adding scope.

This is the part UCP Radar handles. It reads your catalog through the new Merchant API, generates the conversational attributes and optimized standard fields from the product data you already have, and serves them as a Google-spec supplemental feed at a stable URL. You register that feed in your own Merchant Center and keep control of it. Nobody pushes anything to Google on your behalf, and no tool can promise you a ranking. What it does mean is that when the new pipe carries your catalog to Google’s AI surfaces, there is something in the fields worth reading. If you want to see what your current data looks like before any of this, a feed audit is the honest starting point.

Conclusion

The Content API to Merchant API migration has a hard date and a real consequence, so it will get done. The question is what it gets done as. Ported, it is a maintenance task that buys you back exactly what you already had. Treated as the upgrade Google intended, it is the moment your product data starts being legible to the systems that increasingly decide what shoppers see.

Work the checklist: inventory your callers, chase your vendors, map the fields, run in parallel, verify with Google’s own status data. Then spend the small extra effort on the AI fields while the work is open. UCP Radar exists to make that last part something you configure rather than something you build.