Google sunsets Google Ads API developer tokens: access levels now follow your Google Cloud project

Google is sunsetting Google Ads API developer tokens and moving API access levels onto Google Cloud projects. The change was announced on 10 September 2026 by Anash P. Oommen of the Google Ads API Team on the Google Ads Developer Blog, with rollout starting the same day. Signup and access management are also moving from the API Center page in Google Ads manager accounts to a new Google Ads API Overview page in the Google Cloud Console. New Basic and Standard applications now need brand verification, and every pending Basic Access application has been closed.

Existing integrations keep running without code changes, according to Google. The work is administrative: check that the access level landed on the right Cloud project, keep the project's owner and editor lists current, and plan to stop sending the developer token before a future API version starts rejecting it. This follows Google's tightening of the Google Ads Developer Policies on 31 August 2026, which Relevant Audience covered separately.

What Google changed on 10 September 2026

The Developer Blog post groups the changes into two blocks: how API access is managed, and how access applications are reviewed. Google said the aim was to improve the developer onboarding and usage experience, and that it built a new homepage for the Google Ads API inside the Google Cloud Console to do it.

The table below lists each change as Google described it on 10 September 2026, with the status the post gave for it.

One more item sits outside the table because it is a one-off: all pending Basic API access applications were closed as part of the transition. Google said affected applicants will receive an email with details and should reapply from the Google Ads API Overview page.

Signing up no longer requires a manager account

Until now, getting access to the Google Ads API started inside a Google Ads manager account, where the API Center page issued the developer token and showed its access level. Google said on 10 September that developers can now sign up for Google Ads API access directly in the Google Cloud Console, without a Google Ads manager account.

Google is sunsetting all new signup and access management functionality in the API Center and moving it to the Google Ads API Overview page in the Cloud Console. The API Center page is still reachable so developers can refer to their old developer details. Google said that page "will completely sunset in the future" and gave no date.

For agencies this changes where the paperwork lives. The manager account remains the place where client accounts are linked and managed in the Google Ads interface. The permission that decides what an API integration may do is now a property of a Cloud project, which is usually owned by whoever set up the integration: an internal developer, a reporting vendor, or a contractor.

How "access level follows the Cloud project" works

The Google Ads API has used access levels to decide what a caller may do. The Developer Blog post names Test Account Access and Explorer Access, and the review changes cover Basic and Standard Access. Before 10 September 2026 that level belonged to the developer token, a value sent in the header of every API call.

Google's post describes three mechanical shifts.

The level moves to the project that issued your OAuth credentials

Every Google Ads API call is authenticated with OAuth credentials, and those credentials are generated inside a Google Cloud project. Google said API access levels "are now determined by the Google Cloud project you used to generate your OAuth credentials." In practice, the question "what access does this tool have?" is now answered by looking at the Cloud project behind its OAuth client, not at a token string.

The transfer was automatic, based on recent activity

Google said a developer's current and active developer token access level "is automatically transferred to your Google Cloud projects based on recent API activity." The post does not explain how Google matched tokens to projects beyond that phrase. A reasonable reading is that the match came from which projects' credentials had recently been used alongside which token. That is also why Google asks developers to confirm the result, covered in the checklist below. A project that has not made calls recently, or a token that was used with several projects, is where a mismatch would be most likely to show up. That is an inference; the post does not say so.

The token is still accepted, but it no longer does anything

Developers can keep sending developer tokens in API call headers. Google said this "is optional and ignored by the API servers," and that existing code "will continue working without any changes." That is a temporary state. In the same post Google wrote: "We will start rejecting developer tokens in API calls in a future major version of the Google Ads API." It has published new versions of the client libraries that allow API calls without setting a developer token.

The new v25 error and what triggers it

The one behaviour change that shows up as an error is tied to test access. Google said version v25 of the Google Ads API will throw a CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION error if a Google Cloud project with Test Account Access level is used to make calls to a production account. Older API versions throw ACTION_NOT_PERMITTED for the same situation.

Google's fix for the error is to open the Google Ads API Overview page for that Cloud project and apply for Explorer Access.

Two things follow for anyone running a reporting connector or script. First, if an integration suddenly fails against live accounts after 10 September, the likeliest reading of Google's post is that the Cloud project behind its OAuth credentials was mapped at a lower access level than the old token held. Second, error handling that looks for ACTION_NOT_PERMITTED will not recognise the new code on v25, so logs and alerts built on the old string may classify the failure as something else. Both points are practical reasoning from the post rather than statements Google made.

Brand verification and automated Basic Access reviews

The second half of the announcement covers review. For new Basic and Standard Access applications, Google now requires brand verification for the Google Cloud project. Google said existing access holders are not required to complete brand verification, "though it is encouraged."

In exchange, Basic Access reviews are now automated. Google said Basic Access applications "will be reviewed within minutes after brand verification and submission." The post gives no equivalent timing for Standard Access.

Because of the process change, Google closed all pending Basic API access applications in one step. The post describes this as a one-time rejection due to the process updates and gives no count of how many applications were affected. Applicants should expect an email and need to reapply from the Google Ads API Overview page, this time after completing brand verification.

The action-required checklist from Google's post

Google's 10 September post includes an "Action required" section with four items. Here they are in order, with notes on who in a marketing team usually owns each one.

1. Verify your API access. Find the developer token's access level in the manager account's API Center. Then confirm the Google Cloud project shows the same access level on the Google Ads API Overview page. If the levels do not match, reapply from the Overview page or contact Google Ads API support. This needs someone who can see both the manager account and the Cloud project, which in many companies are two different people.
2. Update your API contact email addresses. Open the IAM (Identity and Access Management) page for the Cloud project and make sure the users in the owner and editor roles are current. Google said it will start sending Mandatory Service Announcements (MSAs) to these addresses about future Google Ads API changes. If the project was created by a former employee or an agency that no longer works on the account, those notices go to someone who will not act on them.
3. Change your code. Google encourages developers to stop sending developer tokens in API calls and to move to the new client library versions that work without one. It will reject tokens in a future major version.
4. Reapply if your application was closed. If a pending Basic Access application was closed in the transition, reapply from the Google Ads API Overview page in the Google Cloud Console.

Google said it has published updated documentation and pointed developers to its FAQ page, Google Ads API support and the Google Advertising and Measurement Community Discord server for questions.

Who is affected, and who is not

The change applies to anything that calls the Google Ads API with its own credentials. For advertisers and agencies, that usually means:

• in-house scripts or data pipelines that pull Google Ads data into a warehouse, spreadsheet or dashboard through the API;
• custom bid, budget or reporting tools built by an internal developer or a contractor;
• agency tools that manage many client accounts through a manager account;
• developers and vendors who applied for Basic Access and were still waiting on 10 September 2026.

People who only work in the Google Ads web interface are not affected by this post. Nothing in it changes how campaigns are built, bid or reported inside the Google Ads UI, and it does not ask advertisers without API integrations to do anything.

There is a middle group: advertisers who use a third-party connector or reporting product that calls the API on their behalf. The post is addressed to developers, so the checklist falls on the vendor, not the advertiser. An advertiser in that position can reasonably ask the vendor whether its Cloud project access level was confirmed after 10 September, and whether its client libraries have been updated. The post does not set a deadline for either.

What Google did not say

Several details a planning team would want are missing from the 10 September post:

• No date for rejecting developer tokens. Google said only "a future major version." It did not name the version number or a month.
• No date for the full API Center sunset. The page remains available for reference and will "completely sunset in the future."
• No count of closed applications. The post confirms all pending Basic applications were closed but gives no number.
• No review time for Standard Access. The "within minutes" timing applies to Basic Access after brand verification.
• No detail on the matching logic. Access levels moved "based on recent API activity," with no definition of "recent" and no description of how tokens were paired with projects.

Until Google fills these gaps, the safe position is to treat the token-rejection date as unknown and do the code change during normal maintenance, not after an error appears.

What this means for Thai marketers

The Developer Blog post is global and does not mention Thailand or any other market. The points below are analysis of how the change applies to common setups among Thai advertisers and agencies.

Many Thai businesses get Google Ads data into Looker Studio, Google Sheets or an internal dashboard through a connector or script that someone set up years ago. The person who created the Google Cloud project behind that connector may have left, or may sit at a previous agency. Under the new model that project holds the API access level and receives Google's Mandatory Service Announcements. The first practical step is to find out which Cloud project each integration uses and who is listed as owner and editor on it.

Agencies that manage several clients through one manager account should map each API integration to its Cloud project and check the access level on the Google Ads API Overview page against the old token level in the API Center, while the API Center is still readable. Once that page is fully sunset, the comparison Google asks for gets harder to make.

Teams that were waiting for Basic Access approval for a new tool should check their email for the closure notice, complete brand verification on the Cloud project, and reapply. If an in-house team has no developer, the action item is shorter: ask whoever supplies your reporting or automation tools to confirm they have worked through Google's checklist. A Google Ads management partner can do that audit alongside regular account work, and if the same connectors also feed analytics reports, it is a good moment to review the wider Google Analytics 4 setup they sit in.

FAQ

Do I have to change anything if I only use the Google Ads website?

No, advertisers who only use the Google Ads interface are not affected by the 10 September 2026 changes. The post covers API access, signup and review, and asks developers, not UI users, to take action.

Will my existing Google Ads API scripts stop working?

Not because of the token change, according to Google, which said existing code will keep working without changes. The exceptions are a Cloud project mapped to Test Account Access, which returns CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION on v25 when calling production accounts, and a future major version in which Google will reject developer tokens sent in API calls.

When will Google reject developer tokens in API calls?

Google has not given a date. The post says only that rejection will start "in a future major version of the Google Ads API," and that new client library versions already allow calls without a developer token.

My Basic Access application was pending. What happens now?

It was closed, and you need to reapply from the Google Ads API Overview page in the Google Cloud Console. Google said affected applicants get an email, new Basic applications require brand verification, and automated reviews complete within minutes of verification and submission.

Do existing Basic or Standard Access holders need brand verification?

No, brand verification is required only for new Basic and Standard Access applications. Google said existing access holders are encouraged to complete it but are not required to.

Next steps

The 10 September changes are mostly finished on Google's side: the access levels have already moved, and existing integrations keep running. What remains is on the advertiser's side and takes little time if done now: confirm the access level on each Cloud project, clean up owner and editor roles so Google's notices reach someone who will act on them, and schedule the client library update before a future API version makes the developer token a hard error. If you are not sure which tools in your stack call the Google Ads API, Relevant Audience can help you map them and check each one against Google's checklist.