Google moved Google Ads API access management out of manager accounts and into the Google Cloud Console on Thursday, September 10, 2026, sunsetting the developer token as the unit that determines what an integration is allowed to do. Access levels now attach to Google Cloud projects instead. Every Basic Access application still sitting in the review queue was closed as part of the transition, and the developers behind those applications have to submit again.

In Short

Google changed where API permissions live. Instead of a 22-character developer token issued from a Google Ads manager account, the thing that decides whether your code can touch a live advertising account is now the Google Cloud project you authenticate with. Existing code keeps working, the token you already send is simply ignored, but anyone whose Basic Access application was still pending on September 10 had it closed and needs to apply again from the new page.

Access moves to the Cloud project

The change was published on the Google Ads Developer Blog under the byline of Anash P. Oommen of the Google Ads API Team, the same engineer who has signed most of the access-related posts across the past year. According to Google, the company built a new homepage for the Google Ads API inside the Google Cloud Console, and the surrounding changes began rolling out on the day of publication.

Two mechanics sit at the centre of the post. The first concerns sign-up. Developers can now request access to the Google Ads API directly in the Google Cloud Console without holding a Google Ads manager account at all, a prerequisite that has governed API onboarding since the interface existed. The API Center page inside manager accounts, which previously handled both signup and access management, is being retired in stages. According to Google, all new signup and API access management functionality in the API Center is being sunset and moved to the Google Ads API Overview page in the Cloud Console. The old page stays reachable for reference to legacy developer details, and Google states it will disappear completely at an unspecified later date.

The second mechanic is the one with downstream consequences for code. "We are sunsetting developer tokens," the post states. Current and active access levels transfer automatically to Google Cloud projects, and Google says the mapping is derived from recent API activity rather than from any developer action. Tokens can still travel in the API call headers, but they no longer carry meaning: according to Google, sending one is optional and the value is ignored by the API servers. Access levels are determined instead by the Cloud project used to generate the OAuth credentials.

That phrasing is deliberate. Google is not switching off token transmission, which would break every integration in production overnight. It is severing the link between the token and the permission, leaving the string in place as an inert header field. Existing code continues to run without modification. What changes is the answer to the question of which entity holds Basic, Standard, Explorer or Test Account Access, and that answer is now a Cloud project number.

The v25 error code

One breaking behaviour arrives with the version boundary. Version 25 of the Google Ads API returns a CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION error when a Google Cloud project carrying Test Account Access level attempts a call against a production account. Older API versions return ACTION_NOT_PERMITTED for the same condition. Google directs developers hitting the new error to the Google Ads API Overview page for the relevant Cloud project, where Explorer Access can be requested.

The distinction between the two error codes matters for anyone maintaining error handling across several API versions at once. Under the release cadence Google adopted in January 2026, four major versions ship each year and each remains supported for twelve months, which means a single integration can plausibly be running calls against three supported versions during a migration window. A permission failure that surfaces under one name on v24 and another on v25 is precisely the kind of divergence that produces silent misclassification in logging pipelines built around string matching.

Version 25 itself arrived on July 22, 2026, removing the CustomerLifecycleGoal and CampaignLifecycleGoal resources and forcing rewrites for any pipeline configuring lifecycle goals programmatically. The minor release v25.1 followed on August 19 with lift measurement resources and a set of allowlist-restricted features. Teams that have already migrated to v25 for those reasons inherit the new error code as a side effect of having moved early.

Brand verification becomes a gate

Google restructured the review process alongside the access model. For new Basic and Standard Access applications, brand verification of the Google Cloud project is now mandatory. Existing access holders are exempt from the requirement, though Google says it encourages them to complete it anyway.

Brand verification was not built for the Google Ads API. It originates in OAuth application verification, the identity layer Google applies to applications requesting access to user data across its API estate. Its use in advertising access review began as an optional pilot on July 7, 2026, when Google offered developers a route from a five-business-day Basic Access wait down to hours in exchange for completing the check. Fourteen months of queue pressure separated that pilot from its cause. Google had acknowledged a backlog on February 6, 2026, naming three drivers of application volume: the Explorer Access tier that debuted the same day, the open-source Model Context Protocol server, and the Google Ads API Developer Assistant.

What was optional in July is compulsory in September. The trade Google is offering in return is speed. According to Google, Basic Access applications are now automated and reviewed within minutes of brand verification and submission. The manual queue that produced the February backlog is being replaced by an automated decision that runs once an identity signal is already on file.

Pending applications closed in one sweep

The transition carries a cost that falls entirely on one group. According to Google, all pending Basic API access applications were closed as part of the process update. Affected applicants receive an email with details and have to reapply from the Google Ads API Overview page.

Google frames this as a one-time rejection driven by the process change rather than a judgement on the applications themselves. The practical effect for a developer who submitted an application in the days before September 10 is that the wait resets, this time behind a brand verification step that did not exist as a requirement when the original submission was made. No figure for the number of closed applications appears in the post, and Google has not published one at any point in the sequence running back to the February backlog disclosure.

For a small vendor whose product launch depends on production API access, that reset is a scheduling problem rather than a technical one. For a large integrator with several Cloud projects in flight, it is a coordination problem, since each project needs its own verification and its own resubmission.

The four items Google flagged

The post sets out an action-required section with four items, which read as a map of where breakage is expected.

The first concerns a mismatch check. Google asks developers to confirm that the access level now attached to a Cloud project matches the access level that the corresponding developer token held in the manager account API Center, and to reapply from the Overview page where the two diverge. The automatic transfer is described as being based on recent API activity, which implies that projects and tokens with no recent traffic may not have mapped cleanly.

The second concerns notifications. Mandatory Service Announcements, the channel Google uses to warn of future API changes, will be sent to the email addresses listed in the owner and editor roles on the Cloud project's Identity and Access Management page. Any integration whose Cloud project was set up by a departed contractor, or whose IAM roles were never cleaned up, risks having its change notices routed to an inbox nobody reads.

The third concerns code. Google has published new client library versions that allow API calls without setting a developer token, and states that it will start rejecting developer tokens in API calls in a future major version. The current position, where the header is accepted and ignored, is therefore temporary. No version number or date is attached to the eventual rejection.

The fourth is the reapplication instruction for developers whose pending applications were closed.

A year of tightening the perimeter

The September 10 changes are the latest entry in a sequence that has steadily narrowed who can reach Google Ads programmatically and under what identity.

Credential hardening came first. Google Ads began requiring a passkey for sensitive in-account actions from July 15, 2026, and extended the requirement to new OAuth 2.0 refresh token generation from August 5. Because a passkey cannot be shared, agencies running shared logins were forced to assign individual credentials to each person performing sensitive operations. The developer-facing signal for that shift had landed earlier, in v24.1 on May 13, 2026, through a boolean field named passkey_enabled that let integrations check enrolment state before attempting an operation certain to fail.

Data pathways narrowed in parallel. Customer Match uploads through the Google Ads API stopped working on April 1, 2026, pushing that workload onto the Data Manager API, and new offline conversion imports were restricted from June 15 for developer tokens unable to demonstrate recent active use. Both restrictions used token activity as the qualifying test, which is notable given that the token has now lost its role in the permission model entirely.

Then came the architectural statement. On August 31, 2026, Google published updated Google Ads Developer Policies banning programmatic proxies and requiring every integration to connect through its own dedicated Google Cloud project. A programmatic proxy, in Google's definition, is a third-party hosted interface, secondary API, wrapper service, Model Context Protocol server or similar intermediate layer that re-exposes Google Ads capabilities without routing each end user through a direct, verified connection.

Read against that policy, the September 10 announcement is its enforcement substrate. A rule requiring one Cloud project per integration is difficult to police when permissions are carried by a portable 22-character string that can be lifted from one deployment and dropped into another. Once the access level lives on the project, the policy and the plumbing describe the same object. Google does not make this connection explicitly in the post, and the causal link is inference rather than a stated rationale.

Why the developer base grew in the first place

The pressure that produced the February backlog, the July pilot and now the September automation traces back to tooling Google itself shipped. The open-source MCP server for the Ads API arrived on October 7, 2025 in read-only form, enabling natural-language queries against campaign data. The Google Ads API Developer Assistant expanded through v2.0 in February 2026, adding conversion diagnostics, and was rebuilt as a plugin in v4.0 on August 25, 2026, breaking compatibility with earlier installations.

Each of those lowered the cost of writing a first Google Ads integration. Lowering that cost enlarged the population applying for production access, and an application process designed around manual human review did not scale with it. Automating Basic Access approval closes that loop: the tooling created the demand, and the identity check now absorbs it.

What agencies and vendors carry away

For an in-house team with a single production integration and a stable Cloud project, September 10 is a bookkeeping exercise. The access level moved, the token stopped mattering, and the code runs unchanged.

The exposure sits elsewhere. Agencies and technology vendors managing many client integrations now hold permission state distributed across many Cloud projects rather than concentrated in a handful of tokens, each project carrying its own brand verification status, its own IAM roster and its own access level. Auditing that estate is a different task from auditing a token list, and the automatic activity-based transfer means dormant projects are the most likely to have mapped incorrectly.

There is also a documentation problem sitting behind vendor procurement. Advertisers asking a vendor which developer token underpins an integration are asking a question that no longer has an operative answer. The equivalent question concerns the Cloud project number, its verification status, and whether it is dedicated to that one integration as the August policy requires.

Google published updated documentation alongside the post and pointed developers to its FAQ page, Google Ads API support, and the Google Advertising and Measurement Community Discord server for questions. No deprecation date was given for the API Center page, and no version was named for the eventual rejection of developer tokens in API calls. Both remain open variables in a migration that is otherwise already complete on Google's side.

Timeline

Summary

Who: Google, through Anash P. Oommen of the Google Ads API Team, writing on the Google Ads Developer Blog. The affected population is developers, agencies and marketing technology vendors holding or seeking Google Ads API access, along with the advertisers whose accounts those integrations touch.

What: Google Ads API signup and access management moved from the API Center page in Google Ads manager accounts to a new Google Ads API Overview page in the Google Cloud Console. Developer tokens are being sunset as the carrier of access level, with levels transferred automatically to Google Cloud projects based on recent API activity and tokens in call headers now optional and ignored. Version 25 returns a CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION error where Test Account Access projects call production accounts, replacing ACTION_NOT_PERMITTED on older versions. Brand verification became mandatory for new Basic and Standard Access applications, Basic Access approval was automated to a review within minutes, and all pending Basic access applications were closed with applicants required to reapply.

When: The post was published on Thursday, September 10, 2026, with the changes rolling out from that date. The developer token header will be rejected outright in an unnamed future major version, and the API Center page is scheduled for full sunset at an unspecified date.

Where: Globally, across the Google Ads API, the Google Cloud Console, and the Google Ads manager account interface being retired.

Why: Google states the goal as improving developer onboarding and usage. The change also aligns permission state with the one-Cloud-project-per-integration requirement written into the Developer Policies on August 31, 2026, and replaces the manual review queue that produced an acknowledged application backlog in February 2026 with an automated decision resting on an identity check.