Google gives you 28 days. On October 7, 2026, Google Ads API version 22 stops working, and with it every script, connector, or automation that hasn't migrated to v23 or higher. But the v22 sunset isn't the real news. The real news is what Google has slipped into the same package: a policy banning unverified programmatic proxies and requiring a dedicated Google Cloud project. For security, they say.
TL;DR: The no-nonsense summary
- API v22 End of Life: from October 7, 2026, any call to v22 returns an error. No grace period.
- Proxies banned: Google is blocking unverified programmatic proxies, third-party MCP servers, and any middleware layer that re-exposes its API. Direct connection with a dedicated Cloud project only.
- Real risk for agencies: most agencies have no idea which integrations are still on v22 or which ones run through a middleware layer. Time to audit, now.
- Security or control: the security argument is legitimate, but the net effect is that Google is eliminating every abstraction layer it doesn't own.
What dies on October 7, and what breaks?
The Google Ads API v22 stops accepting requests on October 7, 2026. There is no gradual degradation, no grace period: from that date on, any request to that version returns a hard error. Google confirmed this on its developer blog and has been flagging it since v23 launched in January.

The list of things that break is predictable:
- Your own automation scripts, the ones someone built two years ago and nobody has touched since.
- Data connectors feeding Looker Studio or BigQuery.
- Third-party bidding platforms that haven't updated their integration.
- Any SaaS tool still running v22 under the hood.
The problem for mid-sized agencies isn't the migration itself. It's that NOBODY knows exactly what's running. The script that intern built in 2024. The connector a freelancer set up who's no longer with you. The tool that "works fine, don't touch it." If you skip the inventory, October 7 will show you what you left on v22 the hard way.
Banned proxies: real security or control in disguise?
Since August 31, 2026, Google has banned any unverified programmatic proxy that re-exposes the Google Ads API. The definition is broad: third-party interfaces, secondary APIs, bridge services, MCP servers, or any middleware layer acting as a pass-through to the API.
The security argument holds up, to be fair. A poorly managed proxy is an open door: if that intermediary suffers a breach, it exposes the data of every client running through it. Add in performance issues and it drags you down too. Hard to argue with that.
But something doesn't pass the smell test.
Just as the ecosystem of AI agents and MCP servers for campaign management was gaining real traction, Google slams the door on middleware layers. Third-party-hosted MCP servers are explicitly out of bounds under the new policy.
Google clarifies that AI assistants aren't banned, provided they connect using the developer's own credentials and a dedicated Cloud project. But the layer that let third parties simplify your access to Google Ads is gone. Translation: Google becomes the only approved intermediary between you and your Ads data. The platform sees every integration you connect, and you lose the option to manage Google Ads like any other channel without routing through their infrastructure.
It's not the first time. The removal of brand safety exclusions in DV360 and the forced migration from Display to Demand Gen were heading in the same direction. And the quiet changes to budget distribution were never even announced. The direction is always the same: fewer levers for you, more control for Google.
A 4-step audit before it all breaks
You have 28 days. No time for six-month roadmaps. Open the console, take inventory, and prioritize. As I cover in the complete Google Ads guide, understanding what's running under the hood is what separates a serious manager from one running on blind faith in automation.

1. Identify which version each integration is using
Go to Google Cloud Console, "APIs & Services" section, and select "Google Ads API." Under the "Metrics" tab and the "Methods" table, you'll see the method names your project has invoked. If google.ads.googleads.v22.services appears in any of them, that integration needs migrating.
2. Inventory everything that touches the API
Your own scripts, reporting connectors, third-party tools, bidding platforms. Ask your technical team. Ask your SaaS vendors whether they've already updated to v23 or higher. Google is already on v25, so there's no shortage of versions to land on.
3. Audit your use of programmatic proxies
Does any of your tooling access Google Ads through a middleware layer instead of connecting directly via a Google Cloud project? If yes, you'll need to set up a dedicated project with your own OAuth 2.0 credentials. And knowing Google, their compliance team is probably already taking a look.
4. Prioritize ruthlessly
Anything touching active campaigns and billing data goes first. Historical reports can wait a few days. And if a vendor can't confirm migration in writing, start looking for an alternative. Now, not on October 6.
Google calls all of this technical hygiene. Fair enough, maybe. But when you ban every intermediary that doesn't run through your own infrastructure in one move, the message is pretty clear: play by my rules or don't play at all.
Audit today, migrate this week. And when your vendor tells you they're "working on it," ask for a date in writing. Because October 7 doesn't negotiate with anyone.
Frequently asked questions about the Google Ads API v22 end of life
Does this affect people who manage Google Ads only through the web interface?
No. The v22 end of life only impacts programmatic integrations: scripts, connectors, and tools that call the API directly. If you manage campaigns through the Google Ads interface or Google Ads Editor without external automations, this sunset doesn't affect you.
How long does migrating from v22 to a higher version take?
A simple script can be migrated in hours. An agency with multiple connectors, third-party tools, and legacy scripts may need weeks. The bottleneck is rarely the code itself, it's figuring out what's actually running on v22. Google recommends using the "Methods" table in Cloud Console to identify active versions.

