On August 18, 2026, Google retires the Content API for Shopping. If you have product-sync code built on it — a nightly feed push, an inventory updater, anything — that code stops working on that date. The replacement is the Merchant API.

The first thing most people assume is that this is an OAuth problem: new API, new scopes, re-consent every merchant. It isn't. The Merchant API uses the same OAuth scope as the Content API — https://www.googleapis.com/auth/content. Your existing tokens keep working, no re-consent required.

So if it's not auth, what actually breaks? Three things — and none of them throw a clear error. That's what makes this migration eat afternoons.

1. The silent empty-results trap

You point your code at the Merchant API. The call authenticates fine. And it returns... nothing. No 401, no 403 — an empty list.

The cause is almost always that 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 single biggest time sink in the migration, because it doesn't look like an error — it looks like "this merchant has no products." People burn hours re-checking credentials, scopes, and account IDs when the fix is a one-time project registration.

Two things to probe, every time you see empty results:

Is the Merchant API enabled on the Cloud project?
Is that project registered as an API client for the merchant?
If you're using GMC, doctor checks both with a live probe:

gmc doctor

✓ Credential resolved

✓ Token minted

✗ Merchant API access — project not registered (every call returns empty)

Copy
It mints a token and makes a real call, so a green run means you're actually wired up — not just that your credential is valid.

1. The product shape changed (prices, enums, nesting)

The product resource itself changed. Content API v2.1 kept 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:

Prices are integer micros now. { value: "49.99", currency: "USD" } becomes { amountMicros: "49990000", currencyCode: "USD" } — that's value × 1,000,000. Get the rounding wrong and you've mispriced your whole catalog.
Enums use underscores. availability: "in stock" → availability: "in_stock".
targetCountry became feedLabel. targetCountry: "US" → feedLabel: "US".
You can hand-write that transform, or convert a directory of legacy product JSON in one pass:

gmc migrate products --from content --out feeds

converts Content API v2.1 JSON → Merchant API ProductInput files

prices → micros, enums normalized, fields nested under productAttributes

Copy
It prints a report of what it converted, which fields it remapped, and which it dropped — so you can diff the result before trusting it.

1. The feed-label break that silently stops serving

This is the nastiest one, because it passes every validation and still kills your ads.

Google Ads Shopping campaigns serve products by their feed identity — the (feedLabel, contentLanguage) tuple. After migration, if a product's feed identity doesn't match a primary data source your campaigns target, that product lands in a feed nothing serves from. No disapproval. No error log. It just quietly stops showing in ads.

You want to catch this before you push:

gmc -a 123456789 migrate feed-labels --dir feeds

feed labels:

CA / en 18 product(s) ✗ no matching data source

US / en 102 product(s) ✓ matches a data source

✗ 18 product(s) would land in a feed no campaign targets.

Copy
It cross-checks your migrated labels against the account's actual data sources and tells you which groups would go dark.

Put it in a pipeline: migrate → validate → push

The three traps above are why "just swap the base URL" doesn't work. The move is a small pipeline:

gmc migrate scopes # 1. confirm auth + registration are actually ready
gmc migrate products --from content # 2. transform the catalog to the new shape
gmc preflight --dir feeds # 3. catch disapprovals offline, before upload
gmc migrate feed-labels --dir feeds # 4. make sure nothing silently stops serving
gmc feeds push --dir feeds --data-source # 5. push
Copy
That preflight step is worth calling out: it validates feeds offline — no API call, no auth — for the ordinary disapproval reasons (missing GTIN, promotional text in the title, bad value formats). It exits non-zero on gating issues, so it drops straight into CI and bad feeds never reach Merchant Center.

Start now, not in August

The Content API doesn't sunset gradually — it stops on a date. The migration is a few days of careful work if you do it with slack, or a fire drill if you do it the week before. The traps that cost the most (the empty-results registration trap, the silent feed-label break) are exactly the ones that don't surface as errors, so test for them explicitly.

Disclosure: I build GMC, the open-source CLI used in the examples above — doctor, migrate, and preflight exist specifically because these three traps cost me time first. It's MIT-licensed and free, typed, --json on everything, and covers all 11 Merchant API sub-APIs.

npm install -g @gmc-cli/cli
Copy
Docs and the full migration guide: https://yasserstudio.github.io/gmc/

If you've already migrated off the Content API, I'd genuinely like to hear what bit you that isn't on this list.