There’s a hard date coming, and it doesn’t move.
On August 18, 2026, Google shuts down the legacy Content API for Shopping. Not “deprecates.” Not “starts warning you.” Shuts down. If any part of your Merchant Center setup talks to Google through that API — a nightly feed push, an inventory sync, a price updater, a custom connector your developer built years ago — it stops working that day.
The replacement is the Merchant API, which became generally available in August 2025. This guide walks through who’s affected, what actually breaks, and exactly how to migrate before the deadline turns into a fire drill.
First: do you even need to migrate?
Not everyone does. This change hits API-based integrations only.
You are affected if product data reaches Google through custom code or a tool that calls the Content API — an ERP connector, a headless commerce backend, a bespoke feed script, or an older third-party app that hasn’t updated.
You are not directly affected if you rely on:
- Manual file uploads in Merchant Center
- Scheduled fetches (Google pulling a hosted feed file on a schedule)
- Google Sheets feeds
- A modern feed app or platform that has already migrated on your behalf
If you’re in that second group, your job is simpler: confirm with your platform or app vendor, in writing, that they’ve moved to the Merchant API. Don’t assume. The vendors that haven’t migrated are exactly the ones that won’t email you until something breaks.
If you run custom integrations, keep reading. This is your migration.
The good news: your login doesn’t change
Most people brace for the worst part of any API migration — re-authenticating every merchant, new consent screens, new scopes.
That’s not this migration.
The Merchant API uses the same OAuth scope as the Content API. Your existing tokens keep working. No re-consent, no mass re-authorization of your accounts. That removes the single most painful step from the process.
So if authentication isn’t the problem, what is? Three things — and the reason this migration eats time is that none of them throw a clear error.
What actually breaks — the three silent traps
1. The “empty results” trap
You point your code at the Merchant API. It authenticates fine. And it returns nothing. No 401, no 403 — just an empty list.
The cause is almost always the same: your Google Cloud project was enabled for the Merchant API, but never registered as an API client for the merchant. Until you register it, every request is a well-formed call into the void.
This is the biggest time sink in the whole migration, because it doesn’t look like a failure. It looks like “this account has no products.” Teams burn hours re-checking credentials, scopes, and account IDs when the actual fix is a one-time project registration. Whenever you see empty results, verify two things: that the Merchant API is enabled on the Cloud project, and that the project is registered as an API client for that specific merchant.
2. The product data shape changed
The product resource itself was restructured. Content API v2.1 kept most descriptive fields at the top level. The Merchant API keeps only identity fields at the top and nests everything else under productAttributes. Three transforms bite in particular:
Prices are now integer “micros.” A price of 49.99 USD is no longer value “49.99”. It becomes amountMicros “49990000” — the value multiplied by 1,000,000. Get the rounding wrong and you mis-price your entire catalog.
Enums use underscores. Availability changes from “in stock” to “in_stock”. Any code that writes or reads those string values needs updating.
targetCountry became feedLabel. What used to be targetCountry “US” is now feedLabel “US”. This looks cosmetic. It isn’t — see the next trap.
3. The feed-label break that silently stops your ads
This is the nastiest one, because it passes every validation and still kills your campaigns.
Google Ads Shopping campaigns serve products by their feed identity — the combination of feedLabel and contentLanguage. After migration, if a product’s feed identity doesn’t match a primary data source your campaigns actually target, that product lands in a feed nothing serves from.
There’s no disapproval. No error in the log. The product simply stops appearing in ads. You find out when you notice traffic and sales quietly falling off — often days later. The fix is to cross-check your migrated feed labels against the account’s real data sources before you push, and confirm every product group maps to a source a campaign targets.
Why the Merchant API is worth the work
It’s easy to treat this as a chore Google forced on you. But the Merchant API is a genuine upgrade, not just a rename.
It’s built as a modular set of sub-APIs — products, inventory, accounts, data sources, reporting, and more — so you call only what you need instead of one monolithic interface. It offers better performance and scalability, a cleaner structure, and access to reporting and insights the old Content API never exposed. Once you’re through the migration, you can do more than you could before, not just the same thing differently.
Your migration plan, step by step
Treat this as a small pipeline, not a single switch. Done with slack, it’s a few days of careful work. Done the week before the deadline, it’s a scramble.
1. Audit every integration. List everything that touches the Content API: feed pushes, inventory updates, price syncs, order and returns data, custom dashboards. You cannot migrate what you haven’t inventoried.
2. Enable and register. Turn on the Merchant API for your Google Cloud project, then register that project as an API client for each merchant. This is the step that prevents the empty-results trap. Do it first.
3. Map your data flows. For each integration, map the old fields to the new structure — prices to micros, enums to underscore format, targetCountry to feedLabel, and moving descriptive attributes under productAttributes.
4. Transform and validate offline. Convert your catalog to the new shape and validate it before uploading — checking for the ordinary disapproval reasons (missing GTINs, promotional text in titles, malformed values) so bad data never reaches Merchant Center.
5. Check feed labels against live data sources. Confirm every migrated product group maps to a data source your campaigns target. This is the step that prevents the silent serving break.
6. Test in phases. Migrate one integration or one feed first. Confirm products appear, prices are correct, and ads keep serving. Then move the rest. Don’t cut everything over in one shot.
7. Push and monitor. After go-live, watch impressions, clicks, and disapproval counts for several days. A silent feed-label break shows up as a quiet decline, so you have to look for it deliberately.
The dates that matter
- February 28, 2026 — cutoff for beta users of the older interface.
- August 18, 2026 — the Content API for Shopping shuts down completely.
There’s no gradual sunset and no grace period after the 18th. On that date, unmigrated integrations stop returning data, feeds go stale, inventory and prices stop updating, and Shopping campaigns built on that data can stop serving entirely.
If you sell in a restricted niche, migrate early
For a standard store, a stale feed is a lost week of sales. For a restricted-vertical merchant — supplements, healthcare, research peptides — a broken migration is a compliance problem, not just a revenue one.
When prices convert wrong or availability enums break, your live listings stop matching your website. Mismatched price and availability are two of the fastest paths to a misrepresentation review. If you’ve been through that before, you know how long it takes to climb back out; our complete 2026 guide to Merchant Center misrepresentation suspensions covers exactly which mismatches trigger it. A rushed API migration is a very avoidable way to create one.
The merchants who get hurt by this deadline are the ones who wait. The ones who migrate in a quiet week barely notice it happened.
What to do this week
Confirm whether you run any Content API integration at all — directly or through a tool. If a vendor handles it, get written confirmation they’ve moved to the Merchant API. If you own the code, enable and register the Merchant API today, then work the pipeline above with time to spare. August 18 is a wall, not a ramp.
Related 2026 Merchant Center updates
The API shutdown is one of several 2026 changes. Google is also consolidating its Shopping policies in September 2026, and it has tightened the return policy rules for digital goods, subscriptions, and restocking fees. Keeping feeds accurate through all of it is how brands stay live — see how one brand scaled to $1.5M without a Google Ads ban.
iComChain helps ecommerce brands — especially in restricted niches — keep their Merchant Center feeds compliant and their Google Ads serving through changes like this one. If you’re unsure whether your setup is exposed to the Content API shutdown, book a free 15-minute consultation and we’ll help you check.
Frequently Asked Questions
I upload my product feed manually — do I need to migrate to the Merchant API?
Probably not. This shutdown affects programmatic integrations only. If your product data reaches Google through manual file uploads, a scheduled fetch of a hosted file, Google Sheets, or the Merchant Center interface, nothing breaks for you on August 18, 2026. The less obvious case is third-party apps and connectors, because plenty of them call the Content API behind the scenes without ever telling you. If a platform, agency or app pushes your feed, ask the vendor in writing whether they’ve moved across. Google’s migration overview confirms what’s being retired.
What actually happens on August 18, 2026 if I haven’t migrated?
Google shuts the Content API for Shopping down on that date — its migration guide states the sunset plainly. Calls from unmigrated integrations stop returning data. In practice that means feed pushes fail, inventory and price updates stop landing, your Merchant Center data goes stale, and Shopping campaigns built on that data can stop serving. Nothing fails gracefully or falls back to a manual mode on your behalf. If you own an integration you haven’t moved yet, assume the pipeline is dark from that day until someone rewrites it.
Will I have to re-authenticate every merchant account when I switch?
No, and this is the part that surprises people. The Merchant API uses the same OAuth scope as the Content API, so your existing tokens keep working and you don’t need to push every merchant through a fresh consent screen. What you do need is the one-time developer registration that links your Google Cloud project to the Merchant Center account — that’s separate from OAuth and it’s mandatory. Budget your migration time for endpoints, field mappings and identifiers instead, because that’s where the real work sits.
My Merchant API calls authenticate but return nothing — what’s wrong?
Check registration before you debug anything else. Enabling the Merchant API in your Google Cloud project is only half the setup; the project also has to be registered against the Merchant Center account. Google describes this as a mandatory, one-time step and blocks calls from unregistered projects. Whether you see an authentication error or simply an empty response, the fix is the same. Once registration is done, confirm you’re querying the correct account and data source, since the Merchant API scopes requests by resource name rather than by a bare merchant ID.
Why are my prices wrong after moving to the Merchant API?
Because prices moved to micros. The Content API sent a price as a value string plus a currency string. The Merchant API uses amountMicros as a 64-bit integer alongside currencyCode, where one million micros equals one unit of your currency. So 24.99 becomes 24990000. Port old code without converting and you’ll publish prices off by six orders of magnitude, and a price mismatch between your feed and your landing pages is one of the fastest routes to disapproval. Convert on write, then spot-check live items after your first sync. See the migration overview.
Why don’t my product IDs match after the migration?
The identifier format changed. Content API product IDs looked like channel:contentLanguage:feedLabel:offerId. The Merchant API drops the channel component and uses tildes rather than colons: contentLanguage~feedLabel~offerId. Anything in your code that splits on a colon, or assumes a channel prefix, breaks quietly. Google’s guidance is not to build these strings yourself — read the resource name back off the object and store it. If your feed labels differ from your country codes, that’s usually where mismatches surface first, and the symptom is products that look updated but never actually change. Reference.
Is there a grace period or an extension after the shutdown?
Google hasn’t published one. The migration documentation gives a single sunset date with no staged wind-down and no extension process. Treat it as a wall rather than a ramp. If you’re reading this close to the date and still have an unmigrated integration, the pragmatic move is to keep your listings alive by another route — a scheduled fetch of a hosted feed file, or manual uploads in Merchant Center — while the API work gets finished. That keeps your product data fresh instead of letting it decay while you rebuild.