Google Ads API moves towards two releases a month

What changed

Google’s 12 October announcement says the Google Ads API is planned to move to two releases a month beginning with v26. Google will continue to issue four major releases each year; the other releases will be minor versions limited to new, non-breaking features. The lifecycle model is unchanged: a major release remains available for one year after release, and every minor version sunsets with its parent major version. Google also says its release blog posts and YouTube live events will move to twice a quarter, each covering updates across several releases. The published 2026–27 release and sunset schedules are explicitly tentative, so projected dates, release types and the presence of individual releases may change. Google’s table identifies v26 as a major release projected for October 2026, but the announcement does not establish a precise v26 launch day. The post is credited to Anash P. Oommen of the Google Ads API Team.

For teams that build or maintain Ads API integrations, the practical change is less about a shorter support window than a potentially denser stream of versioned updates. That distinction matters: the announcement says minor releases are non-breaking, but it does not remove the need to assess newly available fields, endpoints, behaviours or workflows when the individual release notes arrive. A sensible operating response is to separate regular release-note review from major-version migration planning. Product, engineering and operations teams can establish a lightweight recurring review that records whether each release is relevant, whether it affects automated workflows, and whether documentation or tests need updating.

The tentative schedule should be treated as planning context rather than a delivery commitment. Avoid setting contractual dates, migration deadlines or launch dependencies solely from projected months. Instead, verify the release notes and current sunset-date documentation before scheduling implementation work. Because minor versions sunset with their parent, teams should retain a clear map of which deployed integration version belongs to which major release. That map can make future migration work more predictable without assuming that every listed minor release will ship. The announcement establishes the planned cadence and lifecycle approach; feature-level impact remains dependent on future, release-specific documentation.

Why it matters for advertisers

It gives API teams an early basis for adjusting release-review, testing and migration routines while making clear that projected dates are not firm launch commitments.