Google Added the Merchant API to Ads Scripts 130 Days Before the Content API Dies

Google Added the Merchant API to Ads Scripts 130 Days Before the Content API Dies
The Content API for Shopping sunsets August 18. The Merchant API replacement just arrived in Ads Scripts.

Google just announced that the Merchant API will be available in Google Ads Scripts starting April 22. That is the replacement for the Content API for Shopping, which stops working entirely on August 18.

From where you are sitting today, that is 130 days. It sounds like enough time. It probably is not.

If you manage Shopping campaigns with custom scripts, and a surprising number of mid-market and enterprise teams do, this is the migration window you are actually working with. The Merchant API enters the Scripts editor on April 22. The Content API goes dark on August 18. That gives you 118 days of overlap inside Ads Scripts specifically. Outside of Scripts, you have had access to the Merchant API for longer, but a lot of teams have not started because the Content API still worked fine.

It will not after August 18. Every product feed, every custom script, every data pipeline connected to the Content API will stop functioning. Not degrade. Stop.

The calendar says 130 days. The migration says 84.

Migration experts tracking this transition recommend 8 to 12 weeks for a full migration. The high end of that range is 84 days. If you are starting from scratch when the Merchant API appears in Ads Scripts on April 22, you are looking at finishing sometime around mid-July. That leaves maybe three weeks of buffer before the August 18 cutoff.

Three weeks of buffer for something that determines whether your Shopping campaigns serve at all. I have seen teams burn through that kind of margin on a single round of QA delays.

And that assumes you start immediately. From what I have read, plenty of teams have not even audited which integrations still touch the Content API. Google has been sending email reminders since January, and warnings are now appearing directly in Merchant Center Next for accounts that have not begun the process. When Google escalates the nudges, it tells you something about adoption rates.

Feed labels are the quiet campaign killer

Most migration guides either bury this or skip it entirely: feed labels do not automatically transfer during the migration.

That sounds like a minor configuration detail until you think about what feed labels actually do. They are the connective tissue between your product feeds and your Shopping campaigns. Migrate to the Merchant API without explicitly reconnecting your feed labels, and your campaigns lose their product data connection. They stop serving. No error message, no gradual degradation. Your listings just vanish from Google Shopping.

This is the kind of thing that breaks on a Friday afternoon and nobody figures out why until Monday. In migration discussions I have followed, it is the single most common oversight, and it carries the harshest immediate consequence.

The fix is straightforward once you know about it. Map every feed label in your current Content API setup, document which campaigns they are connected to, and manually re-establish those connections after migration. Tedious bookkeeping, not engineering complexity. But you have to know to do it.

What the Merchant API actually brings to the table

The Merchant API is not just a forced migration for bureaucratic reasons. The architecture underneath is meaningfully different.

The biggest change is modularity. The Content API was a monolith. One API surface handled product data, inventory, promotions, and account management. The Merchant API splits this into sub-APIs, each handling a specific domain: products, local inventory, regional inventory, promotions, reviews, and notifications.

In practice, that means you can update your product data pipeline without touching your promotions integration. Fewer cascading failures, more targeted updates. If you have followed Google API consolidation in other products (the Data Manager API consolidation is the most recent example), this is actually the reverse direction. Instead of merging pipelines, they are separating them. For something this complex, it is arguably the right call.

There are also genuinely new capabilities that did not exist in the Content API:

  • A Notifications API for real-time updates instead of constant polling
  • A Google Product Studio API for AI-generated product images and descriptions
  • Dedicated endpoints for product and store reviews
  • Better omnichannel inventory support across local, regional, and online channels

The Product Studio integration is worth watching. Whether it is useful today depends on your catalog size and how much of your feed content is already automated. For teams running 10,000+ SKUs with thin product descriptions, it could save real time. For everyone else, it is probably a Q4 evaluation item after you have survived the migration itself.

Use the parallel run or accept the risk

Google recommends running both APIs in parallel during the transition. Send product data through the Content API and the Merchant API simultaneously, compare output, verify data integrity before cutting over.

This is genuinely useful, but only if you start early enough to benefit from it. A parallel run with two weeks of overlap is not a safety net. It is a checkbox. You want at minimum a month of simultaneous operation to catch the edge cases that do not surface in staging: the product variants that serialize differently, the promotional pricing rules that behave slightly off under the new schema, the feed that passes validation but produces subtly wrong data in production.

I would not skip the parallel run if you are managing Shopping campaigns at any real scale. The cost of running both APIs for a month is trivial compared to your Shopping campaigns going dark for even a single day.

Start this month, not this quarter

The April 22 launch is a starting gun for teams that have not moved yet. If I were planning this migration today, here is the sequence:

Week 1 (now, before April 22): Audit every integration touching the Content API. Custom scripts, third-party feed tools, reporting dashboards, anything. If you do not know what is connected, you cannot plan the migration.

Week 2 (April 22 onward): Start with the Merchant API in Ads Scripts. Migrate your simplest script first as a proof of concept. It is available as an Advanced API in the Scripts editor, and the Content API still works alongside it.

Weeks 3 through 6: Migrate remaining integrations in phases. Product uploads first, then reporting, then promotions. Re-establish feed label connections explicitly after each phase. This is where the tedious work lives.

Weeks 7 through 10: Parallel run. Both APIs processing the same data simultaneously. Compare output, verify campaign performance is unchanged.

Weeks 11 and 12: Cut over fully and decommission Content API connections before August 18.

That sequence works if you start now. Delay to May, and you are compressing a 12-week plan into 10. Wait until June, and you will probably cut corners on the parallel run, which is exactly the phase where you catch the problems that cost the most.

The feed managers who start this week will not remember August 18

Google has a pattern with these migrations. They announce timelines that sound generous, and the actual usable window turns out to be about 60% of the headline number once you account for testing, QA cycles, and the inevitable week someone loses to a priority escalation from another project.

This migration is no different. 130 days on the calendar becomes 84 working days of implementation, which becomes maybe 60 days of focused work after the parallel run and QA absorb their share. The teams that treat April 22 as day one of the actual migration, not day one of "we should probably think about this," are the ones who will barely notice the deadline.

Everyone else gets to discover what happens when feed labels do not reconnect themselves on a deadline weekend.