Google Ads API Versions 2026: Releases and Sunsets

Version 26 of the Google Ads API shipped on 14 October 2026, and it arrived with a change to the release rhythm itself: instead of four releases a year, Google now ships roughly twice a month. If you pull spend into a warehouse, push offline conversions from a CRM, or run any homegrown script against the account, that shortens the window in which “it works, don’t touch it” is a viable strategy. Google Ads API versions now expire on a published schedule, and that schedule belongs in a calendar rather than in the memory of whoever wrote the integration.

This piece covers the practical side: what the new cadence looks like, which shutdown dates are already announced, what actually landed in v26, which classes of change silently break pipelines, and how to run a migration that takes half a day a quarter instead of three days of firefighting.

The short version: pin an explicit version in code, put every sunset date on a calendar, re-run your GAQL queries against the new version in a test account once a quarter, and reconcile metric totals over a closed period. Everything else is detail inside that loop.

What changed in the release schedule

Based on trade coverage citing the Google Ads Developer Blog, the autumn 2026 picture looks like this:

v26 was released on 14 October 2026, with a minor v26.1 following later the same month.
Releases are now roughly fortnightly. Minor versions sit between the major ones; they add fields and resources rather than retiring contracts.
Major versions remain four a year: v27 in January 2027, v28 in April 2027, v29 in July 2027, v30 in October 2027. Google notes that dates may move and that it may skip holiday-season releases.
Minor versions retire with their parent major. v26.1 lives exactly as long as v26 — it has no separate lifespan.
Release posts and developer live streams moved to a twice-per-quarter rhythm as well.

Announced sunset dates

Version	Released	Projected sunset	What it means for you
v23	2026	February 2027	Migrate now — less than a quarter of runway
v24	2026	May 2027	Plan the move for Q1 2027
v25	2026	August 2027	Comfortable, but not indefinite
v26	14 October 2026	November 2027	The sensible target for new integrations

Treat these as Google’s stated guidance rather than a contract. Historically sunsets have slipped, and only ever later — but betting on an extension is a poor plan. On shutdown day, calls to a retired version simply stop being served, and that shows up as a silently empty dashboard rather than a clear error anywhere in the UI.

What shipped in v26, and who it touches

v26 is not a cosmetic release. The items below genuinely change schemas and integration behaviour.

Search Lift: new metrics for measuring generated demand

The API gained a SearchLiftKeywordBundle resource, the segments segments.search_lift_keyword_bundle and segments.search_property, and around fifteen new metrics — among them relative_search_lift, normalized_incremental_searches and search_lift_impressions. They are designed to be read alongside Campaign.lift_measurement_config. One important limit: studies cannot be created through the API, only read. If you already measure the branded demand your video spend creates — the mechanics we covered in Brand Lift and Search Lift measurement on YouTube — you can now pull those numbers into a warehouse instead of transcribing them from the interface.

Performance Max for Local Services

A new setting, PmaxCampaignSettings.local_services_enabled, appeared. The catch: it is set at creation and immutable afterwards. The accompanying LocalServicesPmaxCampaignSettings object requires a country code and a Google Business Profile listing_id. Campaign lead associations, a coupon lead type and a message lead conversion category came along with it. For anyone who worked through the Local Services Ads migration into Google Ads, this is the programmatic way to build those campaigns in bulk — but you cannot flip the flag later, so the creation call has to be right the first time.

Enhanced conversions: a boolean became an enum

Customer.enablement_setting and Customer.effective_enablement_setting replace Customer.enhanced_conversions_for_leads_enabled. This is the textbook example of a change that breaks code quietly: where a parser used to read true/false, it now receives an enumeration with several states. A strict parser throws; a lenient one does something worse and treats the value as disabled. If you configured enhanced conversions and check their status programmatically, that branch needs rewriting.

Hotel bid modifier renames

Before v26	In v26
`hotel_date_selection_type`	`user_set_dates`
`hotel_advance_booking_window`	`advance_booking_window`
`hotel_length_of_stay`	`length_of_booking` (`min_days`, `max_days`)
`hotel_check_in_day`	`start_day_of_week`
`hotel_check_in_date_range`	`start_date_range`

Renames are the most underrated failure mode. The request still succeeds; it is the column mapping in your warehouse, keyed on the old name, that stops finding anything and quietly writes zeros.

Smaller items with real consequences

EU political advertising: Campaign.contains_eu_political_advertising became optional for campaigns and Demand Gen ad groups with upgraded targeting that target only non-EU locations and use no proximity or location-group criteria. A new require_eu_political_advertising_declaration field appears on GeoTargetConstant, CampaignCriterion and AdGroupCriterion.
Shopping: Campaign.listing_type now supports Shopping campaigns.
Minimum daily budget: CurrencyConstant now exposes the per-currency minimum. The $5 floor (or local equivalent) for Demand Gen has applied since 1 April 2026, and under-floor budgets return BUDGET_BELOW_DAILY_MINIMUM on v21 and later.

Developer tokens and Cloud Console access

A separate 2026 storyline is how access itself is granted: API usage moved onto Google Cloud projects, and trade sources word the transition differently. Some report that legacy developer tokens stopped being used in September; others say rejection is scheduled for a future major version. The practical conclusion is identical either way — provision access through a Cloud Console project, and do it before an integration fails rather than on the day it does. The step-by-step is in our guide to getting Google Ads API access via Cloud Console.

While you are there, note the developer policy line that a tool which only proxies API calls outward does not qualify on its own. That matters for teams building internal wrappers and handing access to contractors.

This applies to you even if you never write code

The common assumption — “I’m not a developer, the API isn’t my problem” — fails in practice, because nearly every account has at least one path into it:

Looker Studio connectors and similar ready-made data sources, each running some API version underneath.
Reporting and attribution platforms pulling spend and conversions on a schedule.
CRM integrations uploading offline conversions.
In-house scripts someone wrote a year ago and nobody has opened since.
BigQuery exports, which carry their own schema and refresh cycle — the working setup is in our piece on the Google Ads BigQuery Data Transfer.

When a version goes dark, the account keeps running; one data stream stops. It looks deceptively harmless — yesterday’s dashboard is empty, someone assumes the refresh is late, and the gap is noticed a week later, after weekly summaries and client reports have already gone out wrong.

Build a version map before you plan anything

API consumer	Owner	Current version	Where it is pinned	Sunset
Nightly warehouse export	internal analytics	v24	client config in the repo	May 2027
Reporting platform	external vendor	ask support	vendor side	per their answer
Offline conversion upload from CRM	CRM developer	v25	library in the integration	August 2027
Rules and alerting script	media buyer	not versioned the same way	Google Ads Scripts	—

That last row carries a useful caveat. Google Ads Scripts do not track API versions as strictly, which makes them a more durable home for simple automation. Where the line sits between a script and a real integration is the subject of Google Ads API versus Scripts.

Which changes break pipelines most often

Change type	How it shows up	How to catch it early
Field renamed	Column is empty, no errors raised	Diff your query schema against release notes; test on a fixed date range
Boolean replaced by enum	Parser throws, or silently reads “off”	Log the raw response for that field before migrating
New enum value added	Strict parser fails on an unknown value	Map unknown values to “other” instead of raising
Field became required	Create operations rejected	Run write operations in a test account
Resource turned read-only	Writes return a permission-style error	Read the limitations section of the release notes
Version retired	All calls stop being served	Sunset calendar plus a 60-day alert

A quarterly migration loop that takes half a day

The new cadence does not require reacting to every release. A sane policy is to track major versions, move once a quarter, and keep at least one quarter of buffer before any sunset.

Pin the version explicitly in code. Never default to “latest available” — upgrading should be your decision, not a side effect of a dependency bump.
Create calendar reminders at 90 and 30 days before every sunset date. This is the one item on the list worth doing today.
Stand up a test account and exercise every write path: campaign creation, conversion uploads, budget changes.
Reconcile reporting queries on a closed window. Pick a finished month, run identical GAQL against old and new versions, and compare row counts and metric sums. A gap larger than a fraction of a percent is something to investigate, not round away.
Check renamed fields against the release notes and update the warehouse mapping, not just the query string.
Log the API version on every request and alert on version-related errors. That turns a future sunset into a notification rather than an incident.
Do not cut over on a Friday or during peak season. The week before a sales peak is the worst possible time to change how data is collected.

What to reconcile after cutover

Row counts by campaign and ad group for an identical day.
Totals for cost, clicks, impressions and conversions over a closed week.
The fields you join on with the CRM — click and campaign identifiers.
Null handling: a field that used to arrive as zero may now not arrive at all.
Freshness: whether the availability window for recent data has shifted.

Worth remembering that not every discrepancy comes from the API. Sometimes a metric definition changes, and the “break” is in fact a correct new value. We walked through exactly that in the 2026 Google Ads metric changes: the numbers moved while the code was fine.

Reading release notes in ten minutes

A full major-version changelog looks intimidating, but you only need four sections, and you can skim them by keyword.

Removed / renamed. The only part to read in full. Any removed or renamed field is direct work for you, however exotic it looks — it only has to appear in one SELECT.
Type changes. More dangerous than removals, because the request keeps succeeding. Boolean to enum, integer to string, single value to list — all of it slips past tests that check only the response code.
Newly required fields. Only relevant if you write. Read-only integrations can skip it.
Behaviour changes. The sneakiest section: same fields, different contents. New value-attribution rules and changed segment composition live here.

A practical trick: keep a plain text file in the repo listing every field your queries touch. Before each upgrade, grep the release notes against that list — five minutes instead of twenty pages. The same list usually reveals how bloated your queries are; in a typical export, half the requested fields feed no report at all.

The minimal test that catches most problems

Take a closed calendar month and run the same query against your current and target versions. Compare programmatically, not visually: row count, cost total, conversion total and the number of distinct campaign IDs. If three match and one does not, you have localised the problem to a single field in a minute. Row counts differ? Then segmentation changed, and you resolve that before the new version reaches production.

If a vendor or agency owns the integration

Then your job reduces to three questions, asked in writing:

Which Google Ads API version does the integration run on today?
What is your upgrade policy, and how far ahead of a sunset do you move?
How do you notify clients when data for a period came back incomplete?

“We’re always on the latest” is not the best possible answer: automatic upgrades to a brand-new version are exactly where renames and new enum values bite. A good answer sounds like “we stay on N−1 and migrate a quarter before shutdown.”

Checklist for the next quarter

List every API consumer across the account and the MCC.
Record the version for each, plus its sunset date.
Set reminders at 90 and 30 days out.
Confirm that a Cloud Console project provisions your access.
Run your reporting queries against v26 in a test account and reconcile totals.
Update field mappings wherever Google renamed something.
Add API version to request logs and alert on version errors.
Keep risky cutovers out of peak season — our promo peak playbook covers the freeze window.

Where this meets the rest of your reporting

API versioning is one layer. In parallel you have interface reporting that does not depend on it at all: custom columns and the report editor stay usable while an integration is paused. And dashboards in Looker Studio are worth building so the source can be swapped without rewriting every chart — against an intermediate table rather than a direct account connection.

If you are assembling this stack from scratch and would rather skip the known traps, the PPC Rebels team works with exactly this kind of account plumbing day to day, and the running archive of hands-on breakdowns lives in the paid traffic blog.

FAQ: Google Ads API versions

What happens if I miss a sunset date?

The retired version stops serving calls. The account interface keeps working — only your integration breaks: exports, offline conversion uploads, automated changes.

Do I have to adopt every new release?

No. There are still four major versions a year, and minor releases add capability rather than removing it. A reasonable policy is to sit on the previous major and move a quarter before it shuts down.

How is a minor version different from a major one?

A minor adds fields and resources inside the same major version and retires with it. It has no independent lifespan, so plan around majors.

How do I find out which version my reporting tool uses?

Ask the vendor’s support in writing and record the answer. In homegrown setups the version is usually in the client config or the library package name.

Can Search Lift studies be created through the API?

No. v26 added a resource and metrics for reading results; launching studies is still an interface action.

Why did my numbers shift after upgrading?

Three usual suspects: a renamed field that stopped populating a column, a changed metric definition, or a different data freshness window. Reconciling a closed period tells you which.

Is the Local Services setting in Performance Max really permanent?

Per the v26 documentation, yes — it is set at campaign creation and immutable after that. Build those campaigns with the flag already set rather than planning to enable it later.

What should I do about developer tokens?

Move to Cloud Console project access. Sources disagree on exactly when legacy tokens stop being accepted, but the direction is unambiguous, so provision early.

Do Google Ads Scripts need migrating too?

Scripts are not tied to API versions in the same way, which makes simple automation there more durable. They carry their own limits on volume and runtime, so pick the tool by the job.

How often should I check the sunset calendar?

Quarterly is enough if you already set 90- and 30-day reminders. It is also worth skimming major release notes for renamed fields.

Does exporting everything to BigQuery remove the version dependency?

It decouples dashboards from the API, since reports then read your own tables. The loading channel still follows Google’s rules, so versioning does not disappear — it moves one layer down.

Do this today

The minimum viable takeaway is two actions. First, list every place your account sends data outward and find the API version behind each. Second, put the v23, v24, v25 and v26 shutdown dates in a calendar. That alone turns moving between Google Ads API versions from an event into a routine — half a day a quarter, instead of an empty report discovered at the worst possible moment.

Related reading from the same batch: the October 2026 business name rule for ads and the Google Ads and Shopify setup guide.

Google Ads API Versions in 2026: Twice-Monthly Releases and How to Keep Reporting Alive