Google Ads API Sunset Dates: v22 Stops Working in October

Any script, dashboard or AI agent that talks to Google Ads through version 22 of its API has a deadline. Google’s timetable puts the v22 sunset in October 2026, marked tentative, which Google says means it could happen on any day that month. After it, requests to v22 fail.

That makes this the week to check. Google released v25.2 on September 23, so Google’s timetable now lists ten released versions, and the right one to move to depends on how often you want to repeat the job. Below is every live version with its dates, the lifecycle rules Google states, and how to see which versions your code actually calls.

Google’s definitions are blunt. A deprecated version is any version that is not the latest, and it keeps working. A sunset version stops: the API returns an error and Google no longer supports it. New client library releases already drop a version once it is deprecated. Every released version below except v25.2 is already deprecated.

Sunset dates are given to the month. Google publishes projected release months for the next two versions; both are included and labelled. Google’s release notes also record v22.1 (February 25, 2026), v22.2 and v23.3 (both June 24, 2026), which the timetable does not list.

The dates come from Google’s deprecation and sunset timetable, which also lists the minimum client library for each major version. For Java, that is library 41.0.0 for v22 up to 44.0.0 for v25. Minor versions can need a newer library, which the changelog for each language states.

• About a year per major version. Google gives major versions a lifespan of around 12 months and minor versions about 10, and aims to sunset a version a year after release.
• A new major version every three to four months. The table bears it out: v22, v23, v24 and v25 arrived in October, January, April and July.
• At most two upgrades a year. Google says that is the most you should need, and that upgrades do not have to be sequential.

One consequence is easy to miss. Minor versions mostly share the sunset month of their major line, so a minor released late in a cycle gets less time. v25.2 arrived on September 23 and sunsets in August 2027 with v25, about 11 months later. v25 itself gets about 13. The one exception in the current table is v24.2, which sunsets a month after v24.

According to Google’s release notes, v25.2 is additive. The changes most likely to matter to automation work:

• Smart campaign to Performance Max drafts. A new method generates a paused Performance Max draft from an existing Smart campaign, with a validate-only mode that reports conversion issues before anything is created.
• Asset group URL options. Tracking templates, custom parameters and final URL suffixes can now be set on a Performance Max asset group.
• Bid recommendations. Two new recommendation types suggest raising a target CPA or lowering a target ROAS when bids are too low for Search campaigns to enter auctions.
• Benchmarks in percentile tiers, showing where an account stands among other advertisers, and clearer error reasons when Business Profile location sync fails.

Hotel and travel advertisers also get new booking-window and pricing segments. The previous release, covered in our note on v25.1’s AI Max migration fields, shares v25.2’s August 2027 sunset.

The last row matters now. Google’s Customer Match guide steers new integrations to Data Manager, and Customer Match now accepts IP addresses, covered in our post on Customer Match’s new IP and timestamp columns. For teams connecting AI assistants to Google Ads, our Google Ads MCP server guide covers the setup, and the same version rules apply underneath it.

Google’s timetable is precise about what it means, and the ways to misread it follow from its own definitions. The illustrative projects below each read one word wrongly. They are patterns drawn from the lifecycle rules, not client integrations.

Each misreading costs an unplanned upgrade or an outage, which is the real cost the conclusion names. The calendar in the next section is the page that prevents all four.

None of the four needs a change of policy from Google to avoid. Each is answered by a sentence already on the timetable or in the release notes, read before scheduling rather than after an error appears in the logs, which is the discipline the three-to-four-month release cadence makes a routine rather than an emergency.

The callout above says how to see which versions a project calls, and the calendar is what to do with the answer. For each integration, script or agent in the project: the version it calls today, read from the Methods table in the Cloud Console rather than from memory; the sunset month of that version from Google’s timetable, with the first day of the month written as the deadline; the minimum client library for the target version, which the timetable lists for each major version and the per-language changelog refines for minor versions; the planned jump, straight to the newest minor of the newest major line, with the upgrade guides for each skipped major version listed; and the next two sunsets after that, so the calendar already shows when the following upgrade falls.

An illustrative calendar for a reporting pipeline and an agent integration reads: the pipeline calls v22 and must move before October 1, 2026, to v25.2, with the v23, v24 and v25 upgrade guides to work through and the library raised to the v25 minimum; the agent integration calls v24 and can hold until v24’s May 2027 sunset, with a planned move to the v26 line after it ships, which Google projects for October 2026; a new Customer Match feature is routed to the Data Manager API rather than added to either integration. The next two sunsets, February 2027 for v23 and May 2027 for v24, go in the calendar now.

The calendar earns its place because the lifecycle produces a new major version every three to four months and at most two upgrades a year. A project that reads the Methods table once a quarter and updates this page should rarely meet a sunset it did not already have a date for.

Put the quarterly reading itself on the calendar, with an owner, because the Methods table only reports what the project called in the window it shows, and an integration that runs rarely can be missed by a reading taken on the wrong week.

Open the Methods table today and write the calendar for every version it shows. If v22 appears anywhere, that row is this week’s work; the others get their first-of-the-month deadlines now so the next upgrade is a date rather than a discovery.