English
Deutsch
PolskiGoogle Ads API: Cloud-Project Access and the v22 Deadline on 7 October 2026
Management Summary
The Google Ads API connects external software to advertising accounts, for tasks such as reports and automatic campaign updates. Two separate changes affect this connection: access is now approved through Google Cloud projects, which group application settings, and version 22 stopped working on 7 October 2026. Businesses and agencies need both valid access and a supported version. Separating these requirements helps locate failures, including in occasional jobs that daily reporting does not reveal.
Contents
Since 9 September 2026, Google Ads API access has been managed through Google Cloud projects. The separate v22 retirement date was 7 October 2026 and has now passed. Project approval does not restore a retired API version; a newer client library does not grant a project production access. [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 API use in the 90 days before the transition. A long-standing developer token is therefore not sufficient evidence that every project in an organisation has the expected access. [1, 2]
A Cloud project is the container for application settings and API access in Google Cloud. An OAuth client identifies an application that requests access through a user login; a service account provides a separate identity for automated processes. Project access and permission to read or change a particular Ads account are separate approvals.
A fictional agency has 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 and later 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 have been unsupported since 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 deployed dependencies and request configuration both matter. A lock file fixes library versions, and a container image packages a particular installation. Neither proves which API version a request selects. The configured endpoint or version and actual request logs provide that evidence; an upgraded main repository does not update an older deployed job automatically.
- Schedules include crontabs, Cloud Scheduler jobs and other automations. These show the next planned execution, including quarterly jobs that have not run since the retirement date.
A dormant job does not fail merely because the calendar reaches the retirement date. The failure becomes visible when the next request reaches the retired version. Recording the last successful run and the next scheduled run helps reveal this delayed risk.
What applies to third-party tools that access Google Ads on an agency’s behalf?
The project owning the OAuth client determines API access. With a vendor-managed OAuth client, the vendor must handle project approval and API migration. If the tool instead uses an agency-owned client, responsibility for that project remains with the agency. The integration record needs to state which arrangement applies. Customer-account permissions and credentials still need to be valid in either case.
Sources
- Google Ads: new onboarding experience
- Google Ads API: developer-token transition
- Google Ads API v22 sunset reminder
Sources checked: 26 October 2026.
Related articles
