Google Ads switches off v22 on 7 October, and the error will blame your parameters

What actually stops on 7 October

On 7 October, Google Ads begins rejecting every request that names version v22 of its API. Nothing about your account changes. The credentials are fine, the report that ran yesterday was correct, and the request comes back as an HTTP 400 about invalid parameters.

The version number lives in the middle of a URL, between the hostname and the account id, and almost nobody who depends on it has ever seen it. The last three times a version was switched off, it took between nine and nineteen days before one popular automation platform shipped a fixed release — and each of those patches was written by a user rather than by the vendor.

The date has been on the calendar since 2 September. Here is what it actually breaks, and how to tell in ten minutes whether anything of yours is on the list.

What Google announced, and where the date lives

The sunset notice is one paragraph on the Google Ads developer blog:

Google Ads API v22 will sunset on October 7, 2026. Starting on this date, all v22 API requests will begin to fail. Migrate to a newer version prior to October 7, 2026 to ensure your API access is unaffected.

• Google Ads API v22 sunset reminder, Google Ads Developer Blog, 2 September 2026

Read "starting on this date" literally. Requests fail on 7 October, not after it.

That exact date lives in the blog post and, within the developer documentation, nowhere else. Google's deprecation schedule lists v22 with a sunset of "October 2026 (tentative)" and adds that "the sunset could happen any time in that month, and the dates could change". The definitions on that page are blunt about the outcome:

The sunset version can no longer be used. Requests sent to this version will fail on or after the sunset date.

• Deprecation and sunset, Google Ads API documentation

One more property of that schedule, before you go looking at it. Versions vanish from the table once they have been switched off. v21, sunset on 5 August, is no longer listed. If the version you are actually running is already dead, the schedule is silent about it.

The error does not use the word "sunset"

This is the part that costs people days. Here is a real response from a workflow calling a sunset version, captured in a bug report against n8n in August:

{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.ads.googleads.v21.errors.GoogleAdsFailure",
        "errors": [
          {
            "errorCode": { "requestError": "UNSUPPORTED_VERSION" },
            "message": "Version v21 is deprecated. Requests to this version will be blocked."
          }
        ],
        "requestId": "B3xOfhMsRn2-pHE-MA3VQg"
      }
    ]
  }
}

Three things about that payload matter more than the deadline itself.

The status code is 400 and the top-level message is "Request contains an invalid argument". In n8n, what the person saw on screen was Bad request - please check your parameters [item 0]. That sends you to inspect parameters you did not change, in a workflow you did not touch, which is exactly where the time goes.

The word "sunset" appears nowhere in the response. On the wire the version is "deprecated", although Google's documentation treats deprecated and sunset as two different states with different consequences. The reference page for this very error code says something the response never says:

UNSUPPORTED_VERSION — This API version has been sunset and is no longer supported.

• RequestErrorEnum.RequestError, Google Ads API reference

And the truth sits four levels deep, in errorCode.requestError. Anything that flattens an error for display — a platform's error panel, an alert in chat, a log line — shows you the top of that object and discards the bottom.

There is a fourth detail, from the equivalent break in 2025, and it makes diagnosis harder rather than easier. The person who reported that one wrote:

The Google Ads node fails when calling Google services with a "Version v17 is deprecated. Requests to this version will be blocked" error. This failure happens 1 of 4 executions of such node.

• n8n issue #16167, 10 June 2025

Partial failure is the worst available symptom. A run that fails every time gets noticed the same morning. A run that fails one time in four looks like a flaky connection, gets retried, and quietly delivers incomplete numbers into a report somebody else reads.

Whose version number is pinned, and whose moves on its own

The question that decides whether 7 October is your problem is not "do you use the Google Ads API". It is "did anyone ever type a version number, and is it still sitting where they typed it".

Google's guidance for scripts states the rule for those two script rows directly. The apiVersion argument is documented as "the Google Ads API version to query. Sunsetted versions are not allowed. Defaults to the most recent supported version", and the developer blog spelled out the trade five years ago, in wording that still matches the current reference:

If you think that this may negatively affect your scripts, and you want to pin to a specific version, you can still manually specify a version which will override the default and will not update until you are ready to move on to the next version. If you do this, be on the lookout for when Google Ads API sunsets versions, because that will cause your scripts to fail until you update to a newer version.

• Updating Default Reporting Versions in Google Ads Scripts, Google Ads Developer Blog, 1 June 2021

Pinning a version is a reasonable engineering decision. It becomes a trap only because the person who pinned it two years ago is not the person reading the report this month.

Make keeps the version inside your scenario

Make is where this is most likely to be your problem, because there the version is a field, the field lives in the scenario, and the scenario is yours.

In April, a Make user reported both Google Ads apps failing outright:

Both the Google Ads and Google Ads Lead Forms modules are currently broken in Make. All scenarios using these modules are failing with a 404 error. The issue is that Make's modules are still calling v12 of the Google Ads API, which Google has deprecated and sunset. The exact error is: The requested URL /v12/customers/[ID]/googleAds:search was not found on this server.

• a user, Google Ads & Google Ads Lead Forms modules broken - API v12 deprecated (404 error), Make community, 21 April 2026

Notice the shape of that failure: a 404 saying the URL was not found, not the 400 you get through a native integration. Same cause, second face.

The reply came from Make's Community Team, and it is the clearest published description of how the version is stored:

Dev team suggested following workaround which you can use for now: Open the affected module in their scenario (one of: Create an Object, Update an Object, Delete an Object, Search Objects, Search Objects SearchStream Query). Find the "Google Ads API Version" field — it will show an old/invalid value (v12) or appear empty. Select v20 (the current default). Then open the "Account" dropdown — it will now fire the RPC with v20 in the base URL and load successfully. Repeat for any other modules in the scenario that have the same issue.

• a Make community team member, same thread, 21 April 2026

Four things follow from that, and all four apply to 7 October. There is a field called "Google Ads API Version" inside the modules, so the version is a saved setting rather than something the platform keeps current for you. The value does not migrate on its own: in that report it read v12, a version Google switched off in September 2023, while the current default was v20. The repair is manual and per-module — "repeat for any other modules". And it surfaced the way these things usually do, as a user asking the community why everything was broken.

What that thread does not establish is how long the scenario had been sitting on v12, because the same sentence allows for the field having gone empty rather than stale. The part that holds either way is that nothing moved the value for the owner.

Make's own Google Ads app pages never state which API version the modules use. The only place a version surfaces is the generic "Make an API Call" module, where the instruction is to write one yourself:

Note: For the URL field, enter a path relative to https://googleads.googleapis.com. For example, /vX/customers/MY_CUSTOMER_ID where X is the version number.

• Google Ads Campaign Management app documentation, Make

A month before the deadline, Make had published nothing about 7 October, and searches of its community for v21 and v22 returned no threads at all.

What happened the last three times

n8n is the useful case study, because every step of it is timestamped in public. Its Google Ads node has been through this three times, and the numbers improve each round without becoming good.

Now look inside those nine days, because the split is not what anyone assumes.

Google switched off v21 on 5 August. The first public report of the node being broken was a forum thread on 13 August at 17:14 UTC, with a GitHub issue twenty-six minutes later. A pull request followed at 18:05 and was merged into the main branch at 18:57, one hour and seventeen minutes after the issue was opened. Backports to two maintenance branches were merged within another half hour, and n8n 2.34.6 was published the next morning at 07:33 UTC.

Eight days to notice. Fourteen hours to fix.

The other detail in that history is who wrote the patches. All three version migrations — v17 to v20, v20 to v21, v21 to v25 — arrived as pull requests from outside contributors rather than from the n8n team, and GitHub marks each of those authors as an outside contributor on the record. In fairness to n8n, once the report existed the process worked: a bot opened an internal ticket twenty minutes after the GitHub issue, an employee replied in the thread that "this issue was automatically routed to us", and the team merged the fix and copied it into the older release lines. The narrow claim is the one that matters to you. The person who found this one also wrote the fix.

One more number from that history. The pull request moving the node from v20 to v21 was merged on 22 June 2026. v21 was switched off on 5 August 2026, forty-four days later, and Google published the v21 sunset reminder three days after that merge. The node upgraded onto a version with six weeks to live, which is what happens when upgrades are driven by whatever broke today rather than by the schedule.

Updating is not the same as being fixed

The August fix moved the node's URLs from v21 to v25. It did not touch the list of fields the node asks for, and that mattered within a day.

A user posted this two hours after the release:

Looks like this particular issue has been resolved in the workspace version 2.34.6. The module is now using v25. However after testing it, it seems there are some hardcoded fields in the query that have been renamed by Google.

• a user, Google Ads Node -- still using v21 (Depreciated), n8n community, 14 August 2026

Google Ads reports are written in a query language of its own, and it is strict about field names. The follow-up pull request explains what that means in practice, and it applies to any query-based integration rather than just this one:

#36255 moved the Google Ads node to API v25 but left the GAQL field list untouched. The campaign queries still select metrics.video_views, which was removed in v22 and renamed to metrics.video_trueview_views. GAQL requires every field in a SELECT to resolve, so the stale name fails the entire googleAds:search request rather than just omitting that one column.

• n8n pull request #36347, 14 August 2026

One renamed field kills the whole query. Not the column, the request. And the output changes shape for everything downstream: metrics.video_views used to come back as videoViews, the replacement comes back as videoTrueviewViews, and per that same pull request "v25 does not return the old key under any name".

So the real sequence for anyone migrating on 7 October is: change the version, then fix the field names, then fix whatever reads the output. Three steps, of which the version number is the easy one.

There is an awkward footnote for anyone running a pinned n8n version. The field fix was copied back into the older 2.34 line on 17 August, but no 2.34 release came out after 2.34.6. On that line you get the v25 URLs without the renamed field.

Nobody is going to tell you

Google documents one situation in which it may email you about a change, and this is not that situation. The promise of a direct message covers unversioned changes:

Unversioned changes are announced on the official API blog and summarized on the sunset page. If this change affects your API calls or the accounts that you manage, Google may send you a Mandatory Service Announcement email summarizing the change.

• Stay updated with the Google Ads API, Google Ads API documentation

For version sunsets, the same page says only that changes "are announced on the official blog" and that "you should keep track of the blog". That blog is written for developers building against the API. The person whose weekly report is about to go blank does not read it, and has no reason to. This is the same gap as a connector that changes under you: the notice exists, it is accurate, and it is addressed to somebody else.

Platforms relay it unevenly. Zapier has a well-used format for exactly this — the "Action required" articles that name a deadline and the steps, published for Greenhouse, Pipedrive and Zendesk, the most recent of them updated the day after Google's v22 notice. Across three searches of Zapier's help centre there is no such article for Google Ads, and no published statement of which API version its Google Ads integration uses. The charitable reading is that Zapier owns the version, users have no dial to turn, and there is nothing to warn about. That may well be right, and it is also unverifiable from outside, which is its own answer to whether you should worry: you cannot check, so you can only watch the runs.

The same change, arriving without an error

Version changes do not always announce themselves by failing. Google's own BigQuery Data Transfer Service scheduled its own Google Ads connector to move from v22 to v23 in June, and the change log describes what that does to existing tables:

By April 3, 2026, the Google Ads connector will add the columns campaign_start_date_time and campaign_end_date_time to the table schema and populate them with null. After the update to Google Ads API v23 on June 15, 2026, these new columns will be populated with new values and new data type datetime. campaign_start_date and campaign_end_date will be deprecated and populated with null, but will still remain in the table schema.

• Data source change log, BigQuery Data Transfer Service documentation

The connector is not the thing that breaks. The old columns stay in the schema, and after the upgrade they hold nothing. A dashboard reading campaign_start_date shows blanks instead of an error, which means it can be wrong for months without anyone being paged — the same shape as a spreadsheet somebody tidied while the automation kept running.

If a warehouse table or a BI dashboard is fed from Google Ads, check it in the same hour as the version question. It is the same change arriving through a different door.

Four ways to find out which version you are on

1. Google Cloud Console, the method Google itself names. Open APIs & Services, click Google Ads API, and look at the Metrics subtab. Method names in the Methods table carry the version, in the form google.ads.googleads.v22.services.GoogleAdsService.Mutate. This covers everything running through your own Cloud project.
2. The URL, for anything hand-built. There is no version header — the version is the path segment straight after the hostname, as in https://googleads.googleapis.com/v25/customers/1234567890/googleAds:search. In an HTTP step, that is the field to read.
3. The error body, if something is failing already. The @type field names it: type.googleapis.com/google.ads.googleads.v21.errors.GoogleAdsFailure.
4. The module itself, in Make — the "Google Ads API Version" dropdown, per module, per scenario. n8n has no equivalent to look at, because the version is compiled into the node; there the only question is which n8n release you run.

That last point deserves its own warning. If you self-host n8n and have not updated since early August, your Google Ads node is calling v21, which has been switched off since 5 August. That is not a 7 October problem. That is a today problem, and it looks exactly like the 400 above. Updates arriving on their own schedule are their own hazard — n8n Cloud takes them overnight — but this is the opposite case, where not updating is what leaves you on a dead version.

What moving up actually costs

Going from v22 to v23 is not a find-and-replace. The breaking changes Google lists for v23 include one that reaches reporting workflows immediately:

That first row is the same rename BigQuery's connector documented from the other side, which is a useful signal: when a field shows up both in a vendor's breaking changes and in its own downstream product's change log, it is going to reach you one way or another.

Skipping versions is allowed and often sensible. Google's policy says you "don't have to upgrade in strict sequential order", so jumping from v22 to v25 in one move is legitimate. Just budget for the field renames of every version you skip, which is precisely the bill n8n paid when the follow-up pull request opened twenty-one hours after the migration was merged.

What to do before 7 October

1. List every place that talks to Google Ads. Scenarios, workflows, Zaps, scripts, warehouse transfers, anything a contractor built. This list is the whole job; the rest is mechanical.
2. Start with Google Cloud Console. One screen lists every API version your own project has called, which is faster than opening integrations one at a time.
3. Open every Make module and check the "Google Ads API Version" field. Per module, not per scenario. This is the likeliest place for a stale v22 to be sitting right now.
4. Search your scripts for apiVersion. A Google Ads Script without that argument is safe and moves on its own. One with 'v22' in it stops on 7 October.
5. Check which n8n release you actually run, not the one you meant to run. Below 2.34.6 or 2.35.3, the node is on a version Google has already switched off.
6. After changing a version, run the thing and read the output, not just the status. The failure mode of a successful migration is a renamed field and an empty column downstream.
7. Write down when the next one lands. v23 sunsets in February 2027, v24 in May, v25 in August. Google runs about three of these a year, and the notice arrives on a developer blog three to eight weeks ahead.

When this is a job to hand over

An agency with thirty client accounts cannot open thirty scenarios on 6 October. That is what turns this into a job for somebody else — not difficulty, calendar. Thirty accounts is thirty numbers to read, which makes it a list before it is a job, and a list can carry a price agreed in advance. The Make work we take often looks exactly like this: a stack of scenarios where one saved setting has quietly gone out of date.

For everybody else, this is twenty minutes today. Open the modules, read the version, change the dropdown, and do not pay anyone for it.

There is one exception on both sides of that line. Where the numbers feed an invoice or a bonus, somebody has to check the output after the migration and not just the run status, because the renamed-field problem is invisible to a green tick.

When the n8n node broke in August, the advice in the thread was to swap it for an HTTP request node and call the API directly. The person who did it was clear about the cost: "I just don't want to have to handle additional devops of ensuring another http request node is maintained on our end". The workaround for a hardcoded version is to hardcode the version yourself. v25 sunsets in August 2027, and by then nobody will remember that URL was ever a workaround.

Sources

• Google Ads API v22 sunset reminder - Google Ads Developer Blog, published 2 September 2026, read 7 September 2026. The date of 7 October, the wording "all v22 API requests will begin to fail", and the Google Cloud Console procedure for listing which API versions a project has called.
• Deprecation and sunset - Google Ads API documentation, read 7 September 2026. The version timetable listing v22 as "October 2026 (tentative)" and v25 into August 2027, the caveat that tentative dates may change, the definition of a sunset version, the absence of already-sunset versions from the table, and the policy that upgrades need not be sequential.
• RequestErrorEnum.RequestError - Google Ads API reference, read 7 September 2026. The documented meaning of UNSUPPORTED_VERSION.
• Release notes - Google Ads API documentation, read 7 September 2026. The breaking changes listed for v23, including the campaign date field renames, and the v22 metric renames including video_views to video_trueview_views.
• Stay updated with the Google Ads API - Google Ads API documentation, read 7 September 2026. Mandatory Service Announcement emails being tied to unversioned changes, and the developer blog being the announcement channel for version sunsets.
• AdsApp reference - Google Ads Scripts documentation, read 7 September 2026. The apiVersion argument, its default behaviour, and the rule that sunsetted versions are not allowed.
• Updating Default Reporting Versions in Google Ads Scripts - Google Ads Developer Blog, published 1 June 2021, read 7 September 2026. The trade-off of pinning a version in a script, and the warning that pinned scripts fail at sunset.
• Data source change log - BigQuery Data Transfer Service documentation, read 7 September 2026. The Google Ads connector moving from v22 to v23 on 15 June 2026, and the deprecated columns remaining in the schema populated with null.
• Google Ads node -- still using v21 (Depreciated) - n8n community, 13 to 14 August 2026, read 7 September 2026. The first public report of the break, the HTTP-node workaround and the objection to maintaining it, and the confirmation that 2.34.6 moved to v25 while still failing on a renamed field.
• n8n issue #36253 and pull request #36255 - n8n on GitHub, 13 August 2026, read 7 September 2026 through the GitHub API. The full error payload including UNSUPPORTED_VERSION, the timestamps behind the eight-days-to-notice and fourteen-hours-to-fix arithmetic, and the contributor status of the author.
• n8n pull request #36347 - n8n on GitHub, 14 August 2026, read 7 September 2026 through the GitHub API. The GAQL field rename that broke campaign queries after the version migration, and the change in the returned key name.
• n8n issue #16167 - n8n on GitHub, 10 June 2025, read 7 September 2026 through the GitHub API. The v17 break, and the report that it failed one execution in four.
• n8n releases - read 7 September 2026 through the GitHub API. Publication timestamps for 1.100.0, 2.28.0, 2.34.6 and 2.35.3 behind the nineteen, thirteen and nine day figures, and the absence of any 2.34 release after 2.34.6.
• Google Ads & Google Ads Lead Forms modules broken - API v12 deprecated (404 error) - Make community, 21 April 2026, read 7 September 2026. The 404 error text, and the Make Community Team reply describing the "Google Ads API Version" field and the per-module workaround.
• Google Ads Campaign Management app documentation - Make apps documentation, read 7 September 2026. The instruction to enter a version-bearing path in the Make an API Call module, and the absence of API version information elsewhere on the Google Ads app pages.
• Zapier Help Center - searched 7 September 2026 through the help centre API. No article on Google Ads API versions or this sunset, against existing "Action required" deprecation articles for Greenhouse, Pipedrive, Zendesk and OpenAI.