Google Ads API v21 Sunsets August 5 — Why Plugin Conversion Setups Break
Google Ads API v21 sunsets on August 5, 2026, and every request to that version starts failing rather than returning data. WooCommerce stores whose conversion tracking runs through a plugin pinned to an old API version lose offline conversion uploads, enhanced conversions and bid automation silently, because nothing surfaces in the WordPress admin. Google moved to monthly releases in January 2026, so major versions now retire roughly every six months. A maintained server layer versions the integration centrally, turning a platform sunset into one scheduled update instead of many broken plugins.
What Actually Happens on August 5
A sunset is not a deprecation warning. It is the day the endpoint stops answering.
Google confirmed the date on its Ads Developer Blog in June 2026: Google Ads API v21 sunsets on August 5, 2026, and all v21 requests begin to fail from that date. There is no grace period and no soft degradation. A call to a sunset version returns a version-sunset error rather than data.
What breaks is specific, and it is the expensive half of your measurement stack. Offline conversion uploads stop landing. Enhanced conversions field submissions stop being accepted. Customer match and audience uploads fail. Any bid automation, reporting pipeline or third-party tool that reads campaign data through the API returns errors instead of numbers.
What keeps working is the visible half. Your browser-side Google tag still fires on the thank-you page. Your plugin’s status screen still shows a green tick. That asymmetry is the whole problem: the part that fails is the part nobody looks at daily, and the part that keeps working is the part everyone checks.
Google Ads API v21 sunsets on August 5, 2026, after which every v21 request begins to fail instead of returning conversion data.
Why Plugin-Based Setups Break on Sunsets
A plugin pins an API version in code, which means your tracking inherits its maintainer’s release schedule.
When a WordPress plugin talks to Google Ads, it names a version in its source. That string is a hard dependency. It keeps working until Google stops answering, then it doesn’t — and the only fix is a plugin release that changes the string, tested against the new version’s breaking changes.
So the real question for a store owner isn’t whether Google will sunset a version. It’s whether every plugin author in your stack ships an update before the sunset date, and whether you install it in time. With more than 7 million active WooCommerce installations on WordPress.org and roughly 4.46 million live WooCommerce stores tracked in early 2026, that dependency chain is being repeated on a scale that guarantees a long tail of quietly broken setups.
The failure mode compounds because most stores don’t run one integration. They run a GA4 plugin, a Meta pixel plugin, a Google Ads conversion plugin, sometimes a TikTok or Microsoft Ads plugin — each with its own version pin, its own maintainer, its own update cadence, and its own definition of an event. A platform sunset doesn’t hit a system. It hits a collection of unrelated dependencies that happen to sit on the same site.
Then there’s abandonment. A plugin that hasn’t been updated in eighteen months will not be updated for this sunset either, and nothing in your dashboard distinguishes an actively maintained integration from a dormant one until the data stops.
You may be interested in: Google Killed Customer Match Uploads in the Ads API on April 1
The Six-Month Treadmill Nobody Budgeted For
Google’s move to monthly releases in January 2026 halved the useful life of a major API version.
Historically, a Google Ads API version lived about a year after release, with a minimum twenty-week overlap before its predecessor retired. That gave integrators a comfortable annual migration rhythm. In January 2026 Google moved to monthly releases, lifting major versions from three per year to four — and the sunset calendar compressed with it.
Here’s the thing about a compressed calendar: the obvious upgrade target becomes the wrong one. v21 released on August 6, 2025 and sunsets on August 5, 2026. But v22 is projected to sunset in October 2026, which is about eight weeks later. Migrating from v21 to v22 in late July means repeating the same migration before the first one has finished being validated.
| API version | Released | Sunset | Runway from Aug 2026 |
|---|---|---|---|
| v19 | February 2025 | February 2026 | Already sunset |
| v20 | June 2025 | June 2026 | Already sunset |
| v21 | August 6, 2025 | August 5, 2026 | None |
| v22 | October 2025 | October 2026 (projected) | About 8 weeks |
Translation: version migration is no longer an annual chore you can defer to whoever built the site. It’s a recurring maintenance obligation with a two-to-six month clock, and it applies to every destination platform that versions its API — which is all of them.
Google moved the Google Ads API to monthly releases in January 2026, shortening each major version’s useful life to roughly six months.
Version Pinning vs a Central Server Layer
The difference isn’t whether you migrate. It’s how many places you have to migrate.
Both architectures face the same sunset. The distinction is where the version dependency lives and who is responsible for moving it.
With version pinning in plugins, the API version is duplicated across every integration on every site. Five destinations across three sites is fifteen dependencies, fifteen maintainers, fifteen update decisions. Nobody holds a list of them. When one fails, the symptom shows up as a conversion count dip four weeks later, and diagnosing which of the fifteen went quiet is archaeology.
With a server layer, the store sends its events once to infrastructure you control, and that layer owns the outbound integrations. When Google retires v21, the version string changes in one place. Every store connected to that layer is migrated by the same update, on a date somebody chose deliberately rather than discovered from a graph.
Seresa built the Transmute Engine™ around exactly this asymmetry: WooCommerce events land on a first-party server that versions each platform integration centrally, so a sunset is a maintenance ticket rather than an outage. The store owner doesn’t have to know that v21 existed.
You may be interested in: GA4’s Measurement Protocol Quietly Changed Three Times — Is Your WooCommerce Up To Date?
What to Check Before August 5
Four checks, none of which require a developer, and all of which are faster than reconstructing a month of missing conversions.
First, find out which API version your setup actually calls. In the Google Cloud Console, open APIs and Services, select the Google Ads API, and look at the metrics tab — recent calls are listed by version. If v21 appears there, something in your stack is on the clock.
Second, check the changelog date on every tracking plugin you run. Any plugin last updated before June 2026 has not been tested against this sunset, and its author may not have noticed the schedule change either.
Third, note your current Google Ads conversion counts per action before August 5 and compare them a week after. A step change on a single conversion action, with no matching change in orders, is the signature of an API failure rather than a demand problem.
Fourth, write down where each destination integration lives — plugin, container, or server. That inventory is what turns the next sunset into a scheduled task. There will be a next sunset: v22 is projected for October 2026.
Key Takeaways
The short version, for the calendar and the maintenance plan.
- Hard date: Google Ads API v21 sunsets August 5, 2026, and v21 requests fail from that day with no grace period.
- Silent failure: browser-side tags keep firing while offline conversion uploads and enhanced conversions stop, so WordPress shows nothing wrong.
- Faster clock: monthly releases since January 2026 mean major versions now retire roughly every six months, not annually.
- Wrong target: v22 is projected to sunset in October 2026, so migrating one version forward buys about eight weeks.
- Architecture decides cost: version pinning multiplies the migration by plugins and sites; a central server layer makes it one update.
Frequently Asked Questions
The questions store owners ask when a platform deadline lands mid-campaign.
If your tracking plugin or custom integration still calls Google Ads API v21, those requests begin to fail on August 5, 2026 and return a version-sunset error instead of data. Offline conversion uploads, enhanced conversions and any API-driven bid automation stop working. Browser-side conversion tags keep firing, so nothing looks broken in your WordPress admin until Google Ads conversion counts fall.
Not simply the next one. Because Google switched to monthly releases in January 2026, v22 is projected to sunset in October 2026 — roughly eight weeks after v21. Targeting a later version buys a four-to-six month runway before the next required upgrade, which matters most if you maintain integrations across several stores.
Google publishes sunset reminders on its Ads Developer Blog and lists projected dates in its API documentation, but those notices are written for API developers, not store owners. Nothing appears in your WooCommerce dashboard, and most tracking plugins never disclose which API version they call.
No — the API still versions, and someone still has to migrate. What changes is where the version lives. A server layer holds one integration you update once, rather than a version pinned inside every plugin on every site, which turns the sunset into scheduled maintenance instead of an outage you discover weeks later.
References
- Google Ads Developer Blog, “Google Ads API v21 sunset reminder,” June 2026. Read the announcement
- Google Ads API documentation, “Sunset dates,” 2026. View the schedule
- Search Engine Roundtable, “Google Ads API Updates Expected Monthly In 2026.” Read the report
- MageSpark, “WooCommerce Statistics 2026,” citing StoreLeads, January 2026. See the data
- Barn2, “WooCommerce Stats 2026,” citing WordPress.org active installations. See the data
If you’d rather your conversion pipeline survive the next sunset without a plugin audit, see how a first-party server layer handles platform versions.