English
Deutsch
PolskiGoogle Ads API: Cloud-Project Access and the v22 Deadline on 7 October 2026
Contents
Two Google Ads API changes need attention in September 2026. Access management is moving to Google Cloud projects, while API version v22 is scheduled to stop working on 7 October. These are separate conditions: an approved project does not keep an obsolete API version alive, and a newer client does not grant production access to an unapproved project. [1, 2, 3]
The project behind the credentials matters
Google’s new access model associates the access level with the Cloud project used for authentication. For user authentication, that is the project owning the OAuth client. For a service account, it is the project owning that account. Existing access levels were transferred based on recent API use. A long-standing developer token is therefore not sufficient evidence that every project in an organisation has the expected access. [1, 2]
Consider a fictional agency with one daily reporting service and a second application used only for occasional migrations. Both previously used the same approved developer token, but their credentials belong to different projects. The daily service working successfully says little about the second application’s current readiness. The inventory needs the credential’s project, not just the agency’s manager-account ID.
Three layers to keep separate
| Layer | Question |
|---|---|
| Authentication | Which user or service account is making the request? |
| API access | What access level does that credential’s Cloud project have? |
| API version | Is the request sent to a supported version? |
Customer-account permissions remain another part of a working integration. The table is an investigation order, not a claim that three successful checks guarantee every possible operation. Its purpose is to prevent a version problem from being treated as a password problem, or a project approval issue from triggering an unnecessary campaign rewrite.
What to record when a request fails
Google documents CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION in v25 when a project with Test access calls a production account; older versions use ACTION_NOT_PERMITTED for that situation. The current troubleshooting page also lists transition issues affecting some newly approved projects. An approval shown in the console and a failed request can therefore require investigation rather than an immediate conclusion that the credentials are wrong. [2]
Integration record — example fields
Application and responsible team
Cloud project number
Authentication method and credential identifier
Target customer account: test or production
API version observed in requests
Exact error code and request identifier
Time of last successful runThe record needs identifiers, not secret values. A refresh token, private key or client secret does not belong in an incident spreadsheet. For the fictional agency, this record distinguishes a forgotten monthly process from the healthy daily reporting service without changing either account’s campaign settings.
The v22 deadline remains independent
Google’s sunset notice states that v22 requests begin failing on 7 October 2026. The Cloud Console’s API metrics can help identify recently called methods; the method name includes the version. This complements a source-code search because an old deployed job may remain active after the main repository has been upgraded. [3]
A useful review includes scheduled exports, conversion uploads, maintenance scripts and rarely used administrative jobs. A successful dashboard refresh is not enough if the overnight import still calls v22. The migration should be evaluated against the operations the application actually performs, with read-only reporting and write operations checked separately.
A controlled change instead of several simultaneous fixes
A practical sequence first documents the project access state, then upgrades the client and affected request code, then verifies representative operations. Where possible, an isolated test account provides a place to check changes before live writes. The record should distinguish validation from an executed change and retain the resulting resource identifiers.
Google currently permits the old developer-token header but treats it as optional and ignored; its removal is encouraged, with rejection announced for a future major version. That future change should not be assigned the v22 retirement date without a separate announcement. Updated client libraries support requests without the token. [1, 2]
Ownership is part of keeping the integration running
The project owner and editor contacts also become relevant to service announcements. A working integration can still be poorly maintained when notices reach former staff. Reviewing responsibility and alert routing belongs beside the technical migration. The linked passkey article covers a different layer: the human account behind an authorisation. It should not be mistaken for the project-access transition described here.
Related tool
GoogleAds – GAQL Query Explorer
Google Ads API Passkey Requirement: What It Applies To and How to Find Forgotten Authorizations
Questions and answers
How can rarely run jobs that still use v22 be found?
Through several sources, because each one sees only part of the picture:
- The API metrics in the Cloud Console, project by project. They show only calls from the selected project and only within the selected period; a quarterly export that did not run in that period does not appear, and a second project only appears once it is selected.
- The dependencies of the deployed jobs. Each version of the client libraries supports a specific set of API versions, and an old lock file or an old container image keeps a job on whatever version was current when it was built, even if the main repository was upgraded long ago.
- The schedules themselves: crontabs, Cloud Scheduler jobs and automations a team once set up. They show which job will run at all between now and 7 October.
Anything that appears in none of these sources will show up as an error on the deadline at the latest. That is why recording the time of the last successful run for each job in the integration record pays off; an entry months in the past is a candidate for exactly this case.
What applies to third-party tools that access Google Ads on an agency’s behalf?
With user authentication, the project owning the OAuth client counts, and for a third-party tool that project belongs to the vendor. Its access level and its move away from v22 therefore decide whether the connection keeps working; the agency cannot fix this itself, only note it in the integration record and ask the vendor.
Sources
- Google Ads: New onboarding experience, 10 September 2026
- Google Ads API: Developer-token transition and troubleshooting
- Google Ads API v22 sunset reminder, 2 September 2026
Sources checked: 24 September 2026.
Related articles
