A year on the Google Ads API: two hard deadlines and a lot of free leverage

In January, Google shipped v23 of the Ads API and announced that from then on, a new version would land every month. I read the note twice. I’ve spent twelve years writing code that calls this API, and for most of them it changed slowly enough that you could visit it once a year, bump a version number and forget about it.

Then I did what those years have taught me to do. I opened our codebase at Lynt and searched for shoppingcontent.googleapis.com. Every hit is a script that dies on August 18, 2026, the day the Content API for Shopping shuts down. A second date sits behind it, and Google has already moved that one: from February 2027, every remaining Dynamic Search Ads campaign auto-upgrades into AI Max, whether you asked for it or not. September 2026 takes the automatically-created assets and campaign-level broad match first.

Those two dates are the obligations of Google’s API year. Everything else the platform shipped is an opportunity: AI creative services, product-level sales reporting, the Merchant API inside Google Ads Scripts. So I’ll walk the year in priority order, hardest deadline first. For each change: what it is, why it matters for your account, and the exact call, payload or migration to run.

I won’t leave any of it at “you should migrate.” A deadline without a concrete artifact is just anxiety. At every step you get the endpoint that replaces the old one, the experiment payload or the GAQL query, so you can see exactly what to build before the date arrives.

Deadline one: the Content API for Shopping dies on August 18, 2026

This is the hardest date of the year, so it goes first.

What changed. Content API for Shopping v2.1 shuts down on August 18, 2026. Its successor, Merchant API v1, went GA in July 2025, and the intermediate v1beta already sunset on February 28, 2026. The old monolith is replaced by focused sub-APIs. datasources, products, inventories, reports, notifications.

Why it matters for your account. Anything that touches your feed through the old API stops working on that date. Feed uploads, supplemental feeds, custom labels, price and stock updates, disapproval reads. This is not a “nice to migrate”, it’s a hard cutoff. If a daily script keeps your prices in sync, it goes silent on August 18 and your feed drifts out of date until someone notices the lost revenue. I’ve seen that failure mode on real accounts, and the expensive part is never the outage itself, it’s the weeks nobody notices.

What to do. Rebuild your integration for the new sub-API structure. The migration is mechanical. The host, the path and the resource model change, the intent stays the same. Here is the before and after for the most common call of all, a product upsert:

# OLD: Content API for Shopping v2.1 (off on 2026-08-18)
curl -X POST \
  "https://shoppingcontent.googleapis.com/content/v2.1/{merchantId}/products" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "offerId": "SKU-123", "title": "...", "price": {"value":"19.90","currency":"EUR"} }'

# NEW: Merchant API v1 (productInputs sub-API)
curl -X POST \
  "https://merchantapi.googleapis.com/products/v1/accounts/{account}/productInputs:insert?dataSource=accounts/{account}/dataSources/{ds}" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "offerId": "SKU-123", "contentLanguage": "en", "feedLabel": "US",
        "productAttributes": { "title": "...", "price": {"amountMicros":"19900000","currencyCode":"EUR"} } }'

(Endpoint hosts and the sub-API split are from Google’s docs. Confirm the exact request body for your resource in the Merchant API reference before you ship, because field names changed, not just the URL.)

Merchant API v1 is a better API than the Content API it replaces, and that is the part nobody tells you. Three improvements you inherit for free by migrating:

If you’ve been meaning to harden your feed tooling, the shutdown is what finally makes you do it. Rebuild once, and exit with cleaner error handling and fewer round-trips than v2.1 ever allowed.

Deadline two: Dynamic Search Ads become AI Max in February 2027

This is the second change with a fixed date, and it reshapes how much control you hold.

What changed. AI Max for Search reached GA on April 15, 2026 after launching in beta in May 2025. The rollout comes in two steps: from September 2026 Google auto-upgrades campaigns using automatically-created assets and campaign-level broad match, and the DSA sunset and auto-upgrade themselves begin in February 2027, moved back from the September date Google announced first. After that you can’t create a new DSA campaign. Not in the UI, not in Editor, not through the API.

Why it matters for your account. You trade control for lift. With the full feature set (search-term matching plus text customization plus final-URL expansion) Google reports about +7 % conversions or conversion value over search-term matching alone. In return you hand the model the matching, the asset text and the landing-URL choice. If you have brand or compliance rules baked into your DSA setup by hand, a silent auto-upgrade can start sending traffic to URLs you never signed off on, using ad copy you never approved. Automation you didn’t measure is automation you don’t control.

What to do. Don’t wait to find out what the upgrade does to your numbers. Measure it now. Google shipped the guardrails and the measurement hooks through the API in step with the feature, so you can A/B the switch on your own data before it’s mandatory:

The practical move is the ADOPT_AI_MAX experiment. Create one across your accounts and let it run. Read the CPA and ROAS delta by comparing the experiment arm campaigns with the control campaigns. Then a normal GAQL pull shows you what the keywordless expansion actually matched and earned:

-- After ADOPT_AI_MAX runs: inspect automated expansion performance.
-- Calculate trial/control delta separately from the experiment arm campaigns.
SELECT campaign.name,
       metrics.conversions,
       metrics.conversions_value,
       metrics.cost_micros
FROM targeting_expansion_view
WHERE segments.date DURING LAST_30_DAYS

(ADOPT_AI_MAX is one of the new experiment types shipped in v24.1; targeting_expansion_view is the v22 reporting resource. Confirm field availability in the release notes for the version you call.)

The rolling deadline: a release every month

Not a single date, but a clock that’s now always ticking.

What changed. From v23 (January 28, 2026) the Google Ads API shifted to a monthly release cadence. Four major versions a year plus monthly minor versions, with one year of support per major version.

Why it matters for your account. Faster access to features, and faster obsolescence. Versions age out on a published schedule. v20 reaches end-of-life in June 2026, v21 in August, v22 in October. A monthly minor bump is non-breaking. Missing a major sunset means your scripts start returning errors with no warning beyond a date in a calendar you weren’t watching.

What to do. Pin your version and watch the sunset calendar. The cheapest insurance is a recurring check that knows which version you call and alerts about 60 days before that version expires. The whole thing is a few lines:

# Recurring guardrail: alert ~60 days before your pinned version sunsets.
from datetime import date

PINNED = "v22"                 # the version your client is pinned to
SUNSET = {"v20": "2026-06-01", "v21": "2026-08-01", "v22": "2026-10-01"}  # sunset-dates page
sunset = SUNSET.get(PINNED)    # None until your version reaches the published calendar
if sunset and (date.fromisoformat(sunset) - date.today()).days < 60:
    alert(f"{PINNED} sunsets {sunset}; schedule the version bump")  # major bump needs a re-test

A 404 from a sunset version is a self-inflicted outage. Treat version governance as a standing recurring task, not as a last-minute emergency.

Now the upside: AI moves into creative and feed

With the deadlines handled, the rest of the year moves at whatever pace you set. Two services turned asset and feed work into something you can script across thousands of SKUs.

• AssetGenerationService (Ads API, v22, closed beta). AI text and image generation, with PMax image enhancement and extraction; v23.2 added VideoEnhancement for Google-generated video. Creative generation moves out of the UI into a programmable layer.
• Product Studio (Merchant API, alpha since April 2025). AI-generated product titles and descriptions, plus AutomatedDiscounts for real-time pricing. Rewriting titles at the API level means bulk-improving thousands of SKUs without manual work.

I have a personal stake in the feed half of this. We spent two years building Boostora at Lynt, an AI layer that enriches Merchant Center feeds, because feed quality is the ceiling on Shopping and PMax performance. Better titles move more revenue than most bid changes do. Product Studio brings a piece of that capability into the platform itself.

The pipeline this unlocks reads a SKU from the feed, generates a compliant title, description and image assets, and pushes them straight into the asset group, with no manual Canva step in the middle. Both services are pre-GA. Treat them as a pilot on a slice of the catalogue, not a catalogue-wide rollout, until they reach GA.

The plumbing: Ads and Merchant finally meet

The most underrated change of the year is unglamorous. The two halves of an e-commerce account end up in one place.

What changed. As of April 22, 2026, the Merchant API is reachable from Google Ads Scripts. Combine that with product_filters (conditional feed sharing with Google Ads, shipped November 2025) and CartDataSalesView (v24), and the loop from feed status to ad spend closes inside one environment.

Why it matters for your account. The old split kept campaigns in Scripts and the feed somewhere else. A disapproved product went on burning budget until a human noticed. Now one script can react to a feed disapproval by pausing a campaign or pulling the SKU from a PMax listing group. And CartDataSalesView brings cart-level revenue per sold SKU into the API. It carries revenue, not spend, so real SKU ROAS takes two queries. Start with the revenue side:

-- Revenue per sold SKU from cart data (v24+)
SELECT segments.product_item_id,
       metrics.revenue_micros,
       metrics.all_revenue_micros
FROM cart_data_sales_view
WHERE segments.date DURING LAST_30_DAYS
ORDER BY metrics.revenue_micros DESC

Then pull the cost side from shopping_performance_view and join the two results on product_item_id:

-- Cost per advertised SKU; join to the revenue query on product_item_id
SELECT segments.product_item_id,
       metrics.cost_micros,
       metrics.conversions_value
FROM shopping_performance_view
WHERE segments.date DURING LAST_30_DAYS
ORDER BY metrics.cost_micros DESC

Those joined rows are the input to the profitability tiers you used to rebuild by hand every month. We run customer-level business reporting for clients in BigQuery, and half the work has always been stitching ad data to product data. Two API calls now do the stitching that used to take a feed export, and you can verify the result yourself. Check that the item IDs match in both queries before you trust the ratio. (The resource is cart_data_sales_view, shipped in v24; confirm segment availability in the release notes for your version.)

The year on one timeline

Every major version below comes from the official release notes; the Merchant milestones from the Merchant API latest updates. The right-hand column is the only one that should drive your calendar. Every row that carries the HARD flag is non-negotiable.

The first hour of work

Not the whole migration. A grep. Search your codebase for shoppingcontent.googleapis.com and write down every job that comes back. That list is everything you have at risk on August 18, and it took you ten minutes.

Then spend the rest of the hour creating one ADOPT_AI_MAX experiment on the account where DSA matters most, so the upgrade arrives as a measured change instead of a surprise. The deadlines are Google’s. Whether they hit you as outages or as upgrades is still your call.

FAQ