Google Ads API Access in 2026: Cloud Projects Replace Developer Tokens

Since 9 September 2026, Google Ads API access is granted per Google Cloud project instead of per developer token. What changed, how to set up access today, and what the June 2026 setup guide still gets right.

What changed on 9 September 2026

Our June 2026 guide to Google Ads API setup, authentication, read and write operations was built around the developer token: request it in the API Center of a manager account, apply for Basic access there, and send the token with every call. Three months later that foundation moved. Google's own documentation now states it plainly: "Developer tokens were sunset on September 9, 2026."

The access decision itself did not disappear - it moved. Your API access level is now determined by the Google Cloud project you used to generate your OAuth credentials, and existing access was migrated to Cloud projects automatically. Applications are no longer made in the API Center; Google asks developers not to sign up for a developer token there and to request access from the Google Ads API Overview page in the Google Cloud Console instead. Basic applications that were still pending in the API Center were closed and have to be submitted again from the Cloud Console.

The June guide stays online as published, with a dated note at the top. This follow-up covers what is different today, and links back wherever the earlier material still applies.

Access levels now belong to the Cloud project

The levels themselves are familiar, with one addition. The limits below are taken from Google's access-level documentation as of October 2026:

Access level	Production accounts	Daily operations
Test	No, test accounts only	15,000
Explorer	Yes	2,880 against production accounts
Basic	Yes	15,000
Standard	Yes	No general cap (individual services can still be limited)

Explorer is the practical entry point. According to Google, an application from the Cloud Console is reviewed automatically and, in most cases, upgraded to Explorer access - enough for internal reporting and modest automation on your own accounts. Basic and Standard still require a review, and both now have a new prerequisite: brand verification of the Google Cloud project. Standard additionally involves a manual audit.

The problem is that brand verification is easy to overlook when the technical setup already works. A script running on Explorer access will behave correctly until it reaches the daily limit, so plan the verification before the volume arrives, not after.

Setting up access today

The sequence is shorter than before, because the Cloud project is now the single place where access is decided:

Create a Google Cloud project, or choose the one that will own your Google Ads integration. Billing is not required for this.
Enable the Google Ads API in the project's API Library.
Create the credentials in that same project - an OAuth client for user-based access, or a service account with a JSON key.
Apply for access on the Google Ads API Overview page in the Cloud Console, and complete brand verification if you need Basic or Standard access.

What matters here is step 3. Because access follows the project that issued the OAuth credentials, credentials from a second, unrelated project will not inherit the access level you applied for. Teams that created test clients in separate projects over the years should consolidate before relying on production access.

The OAuth details from the June guide - the adwords scope, offline access for a refresh token, the reasons a refresh token stops working - are unchanged and still apply.

Authentication and configuration

The developer token is now optional in practice. Google says you can continue sending it in your request headers, but the servers ignore it, and a future major API version is expected to reject it. Version 32.0.0 of the official Python library removed the check that required a token in the configuration.

A minimal google-ads.yaml for user-based OAuth therefore looks like this:

client_id: YOUR_CLIENT_ID.apps.googleusercontent.com
client_secret: YOUR_CLIENT_SECRET
refresh_token: YOUR_REFRESH_TOKEN
login_customer_id: "1234567890"
use_proto_plus: true

For a service account, json_key_file_path replaces the three OAuth keys, optionally combined with impersonated_email. Every key can also be set as an environment variable with the GOOGLE_ADS_ prefix, for example GOOGLE_ADS_JSON_KEY_FILE_PATH - the more sensible choice on servers, where configuration files tend to end up in backups and repositories.

login_customer_id keeps its old meaning. When you reach a client account through a manager account, it names that manager account (digits only, no hyphens). Without it, such calls fail with USER_PERMISSION_DENIED.

Versions and the Python library

Version pinning deserves more attention than it usually gets. The June guide used version="v22", and that version is no longer available: release 33.0.0 of the google-ads Python library removed v21 and v22. As of October 2026 the current API version is v26 (released 14 October 2026), and library 34.0.0 adds support for it.

from google.ads.googleads.client import GoogleAdsClient

client = GoogleAdsClient.load_from_storage("google-ads.yaml", version="v26")

Pinning the version explicitly is still the right default. In reality, an unpinned client silently changes behavior on the next library upgrade, and Google retires API versions on a published schedule - a pinned version at least turns that retirement into a planned change instead of a surprise.

The EU political advertising declaration

One requirement has caught many existing integrations: the contains_eu_political_advertising field on the Campaign resource. In API versions before v26, every new campaign must declare it. Since 1 April 2026, mutate calls fail with EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED when an account still contains undeclared campaigns. Version 26 relaxes this: the field becomes optional for campaigns that do not positively target the EU.

Declaring it explicitly costs one line and keeps campaign-creation code valid across versions:

campaign.contains_eu_political_advertising = (
    client.enums.EuPoliticalAdvertisingStatusEnum.DOES_NOT_CONTAIN_EU_POLITICAL_ADVERTISING
)

What carries over from the June guide

Most of the earlier walkthrough is about working with the API rather than getting into it, and that part has aged well. GAQL read queries, the validate_only pattern for testing write operations safely, explicit update_mask handling and the separation between manager account, Cloud project and target account all apply as described. What no longer applies is the access path: the API Center, the developer-token application and the token-based architecture diagram.

A good integration - internal script or client-facing tool - treats access as configuration owned by one clearly named Cloud project. That was a sensible practice before September 2026. Since then, it is how Google defines access in the first place.