# Google Ads API access in 2026, now that developer tokens are gone

Access levels, brand verification, the new error codes and a migration checklist, checked against Google's developer pages on November 7, 2026.

*By Stan Rymkiewicz, maintainer of adwarp. Updated November 7, 2026.*

[Google sunset Google Ads API developer tokens](https://developers.google.com/google-ads/api/docs/api-policy/developer-token) on September 9, 2026, and API access now belongs to the Google Cloud project that owns your OAuth client or service account. Enabling the API gives Test access, and you apply for Explorer (2,880 production operations a day, approved automatically in most cases), then Basic or Standard, on the Google Ads API Overview page in Cloud Console.

1. Open the Google Ads API Overview page for your Cloud project and read its access level.
2. If it says Test, expand Upgrade access level and apply for Explorer.
3. For keyword planning, or for more than 2,880 production operations a day, complete brand verification and apply for Basic.
4. Stop sending the `developer-token` header once your client library supports it.

*Checked on November 7, 2026 against Google's developer token, access levels, brand verification and rate sheet pages (all last updated October 30, 2026) and its quick start (last updated November 4, 2026).*

## What changed on September 9, 2026

Until September 9, a developer token was a 22-character string from the API Center of a Google Ads manager account, and the access level rode on it. Now the level belongs to a Cloud project: the one that owns your OAuth client ID and secret, or, if your code signs in as a service account, the one the service account lives in.

*Fig. 01: The access level moved off the token and onto the Cloud project, so the project you sign in with now decides what you can call.*

Here's the change row by row, from Google's [developer token page](https://developers.google.com/google-ads/api/docs/api-policy/developer-token) (last updated October 30, 2026):

|  | Before September 9, 2026 | Since September 9, 2026 |
| --- | --- | --- |
| Apply in | API Center in a Google Ads manager account | Google Ads API Overview page in Cloud Console |
| What holds the access level | The developer token | The Cloud project that owns your OAuth client or service account |
| Manager account | Needed to get a token | Needed only to manage several accounts |
| Token in each request | Required `developer-token` header | Optional and ignored, rejected in a future major version |
| Who gets Google's notices | The API Center contact email | Owners and Editors of the Cloud project, with the API Center email kept for now |
| New API Center applications | Processed | "won't be processed" |

Sending a token is, in Google's words, "optional and ignored by the API servers," so code that still sends one keeps working for now. The same page says Google "will start rejecting developer tokens in API calls in a future major version" without naming the version. You can still open the API Center to look up old developer details until Google removes it. The new onboarding was announced on the [Google Ads Developer Blog](https://ads-developers.googleblog.com/2026/09/new-onboarding-experience-for-google-ads-api.html) on September 10, 2026, a day after the sunset date.

Skip the "Page Summary" boxes at the top of Google's pages, which lag behind the text under them. On November 7 the box on the developer token page still said a token "is required to make calls to the Google Ads API," and the quick start's box still sent readers to a manager account to get one. The access levels box was counting 3 levels.

### What happened to tokens you already had

Google read the API call logs for the 90 days before September 9 and gave each approved token's level to every Cloud project that had called the API with it. Its FAQ walks through an example with 4 tokens, shortened here:

| Token (Google's example) | Used with | Each project's level now |
| --- | --- | --- |
| Token 1, Standard | 3 projects | Standard on all 3 |
| Token 2, Basic | 1 project | Basic |
| Token 3, Basic, approved within the 90 days but never used | No project | Nothing transferred |
| Token 4, Standard, unused for 90 days | 1 project, more than 90 days earlier | Test, revoked for inactivity |

*Fig. 02: In Google's 4-token example, Tokens 1 and 2 passed their levels to every project that had used them, and the 2 tokens that sat unused left no project above Test.*

A project that never touched any token starts at Test. Moving an old token onto a new project doesn't work either. Google stopped doing those re-associations on September 9, so a call from the new project to a production account fails with `CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION` until that project has its own approval. Leaked tokens stopped mattering too, since nobody can use one with their own project, and Google says you don't need to reset yours.

### The 1 exception: the App Conversion Tracking API

Developers who need the App Conversion Tracking API should keep signing up for a developer token in the API Center, per a note in the signup section of Google's developer token page.

## The 4 access levels, and what Explorer blocks

Every Cloud project has 1 of 4 levels. Google's [access levels page](https://developers.google.com/google-ads/api/docs/api-policy/access-levels) and developer token page (both last updated October 30, 2026) give the limits and the review times:

*Fig. 03: The 4 access levels with their production operations a day from Google's access levels page (October 30, 2026), drawn as steps rather than to scale, with Explorer in orange because it's approved automatically and blocks keyword planning.*

| Level | Accounts | Operations a day | How you get it | Review | Blocked on this level |
| --- | --- | --- | --- | --- | --- |
| Test | Test accounts only | 15,000 | Enable the API | Automatic | Every production account |
| Explorer | Test and production | 2,880 on production, 15,000 on test | Apply on the Overview page | Automated, approved in most cases | Account creation, user management, planning, billing |
| Basic | Test and production | 15,000 | Brand verification, then apply | Within minutes of applying | None of the above |
| Standard | Test and production | Unlimited | Start application on the Overview page | Manual audit, 10 business days | None, though permissible use applies |

Explorer blocks these services by name:

- Account creation: `CustomerService.CreateCustomerClient`
- User management: `CustomerUserAccessInvitationService`, `CustomerUserAccessService`
- Planning: `KeywordPlanService`, `KeywordPlanIdeaService`, `KeywordPlanCampaignService`, `KeywordPlanCampaignKeywordService`, `KeywordPlanAdGroupService`, `KeywordPlanAdGroupKeywordService`, `AudienceInsightsService`, `ReachPlanService`
- Billing and payment: `PaymentsAccountService`, `BillingSetupService`, `AccountBudgetProposalService`, `InvoiceService`

Keyword suggestions and search volumes come out of `KeywordPlanIdeaService`, so a keyword research tool fails on Explorer while reporting and campaign edits from the same project go through.

*Fig. 04: An Explorer project can pull reports and edit campaigns, but keyword ideas stop at the planning block until the project reaches Basic.*

"Per day" means a sliding 24 hours of requests from the project, so a burst at 11 at night still counts against you at 10 the next morning. Google's [rate sheet](https://developers.google.com/google-ads/api/docs/api-policy/rate-sheet) (last updated October 30, 2026) counts 1 search or report as 1 operation however many rows come back, and each item in a mutate as 1 operation. Its own examples: a search that returns 53 ad groups counts as 1, and a mutate that changes 2 ad groups counts as 2. Spread over a day, 2,880 comes to 2 operations a minute.

*Fig. 05: Google's rate sheet counts a search as 1 operation whether it returns 53 ad groups or 1, and counts a mutate by the items it changes.*

Permissible use only applies at Standard, where Google assigns ad creation and management, reporting, or keyword and recommendation research based on what you said the tool is for.

## Get access from scratch

You need a Cloud project, the API switched on and an approved level. These steps follow Google's [quick start](https://developers.google.com/google-ads/api/docs/get-started/make-first-call) (last updated November 4, 2026) and the developer token FAQ:

*Fig. 06: Access takes 3 stops in Cloud Console and then a choice of sign-in, and the Explorer application is the stop that opens production accounts.*

1. Pick or create a Cloud project and check its billing. Under a known issue, Free Trial projects and suspended or disabled billing accounts get Explorer and Basic rejected.
2. Enable the Google Ads API. That alone grants Test access, which only reaches test accounts.
3. Check your role. Managing access levels takes quota permissions, which come with Owner, Editor, Quota Administrator and Service Usage Admin.
4. On the Google Ads API Overview page, expand Upgrade access level, confirm the next level reads Explorer and click Apply for access. Google reviews it automatically and upgrades most projects.
5. Choose how your code signs in: a service account or an OAuth desktop client.

*Fig. 07: The Google Ads API Overview page shows the project's access level, and Upgrade access level opens to the next level and an Apply for access button.*

### The service account route

Use this for code that runs unattended, like a nightly report on a server. In Cloud Console, go to IAM & Admin, then Service Accounts, pick the account and choose Keys, Add key, Create new key, JSON. The downloaded file is the only copy of the key, so keep it out of version control.

Then sign in to Google Ads as an administrator, open Admin, then Access and security, and add the service account's email under Users with an access level. The Email access level doesn't work for service accounts, and you can't grant Admin during the first setup, only afterwards. Passkeys don't apply here: Google's [passkey post](https://ads-developers.googleblog.com/2026/07/passkey-authentication-requirement-for.html) says service account workflows are unaffected.

### The OAuth desktop client route

Local command-line tools and Model Context Protocol (MCP) servers use this route: you sign in once in a browser on your own machine, and the tool keeps a refresh token. Create an OAuth client of type Desktop app in the same project. 2 settings decide whether it keeps working.

Google's [OAuth 2.0 overview](https://developers.google.com/identity/protocols/oauth2) (last updated October 29, 2026) says a project with an External consent screen in "Testing" gets refresh tokens that expire in 7 days. Publish the app to In production, which brand verification asks for anyway.

The other setting is a passkey. From August 5, 2026, Google began requiring one to create a new refresh token through the user sign-in flow, rolling out to all users over the following weeks, according to its passkey post of July 27. Password-only sign-in and one-time codes no longer get through, though existing refresh tokens keep working. Google's [security requirements page](https://developers.google.com/google-ads/api/docs/oauth/security-requirements) warns that "A 7-day security delay may apply before a new passkey becomes trusted and operational," so create yours at g.co/passkeys a week or more before you need to sign in.

*Fig. 08: A new passkey can take 7 days to become trusted before you sign in, and if the consent screen is still in Testing, the refresh token you get then expires 7 days later.*

### Your first call, no token

This follows the curl example in Google's quick start, which calls version v26 and sends no `developer-token` header. It signs in as a service account:

`first-call.sh`:
```bash
gcloud auth login --cred-file=credentials.json
ACCESS_TOKEN=$(gcloud auth print-access-token --scopes='https://www.googleapis.com/auth/adwords')

curl -X POST \
  "https://googleads.googleapis.com/v26/customers/1234567890/googleAds:searchStream" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "login-customer-id: 9876543210" \
  -d '{"query": "SELECT campaign.id, campaign.name FROM campaign ORDER BY campaign.id"}'
```

*Fig. 09: The request keeps its Authorization and login-customer-id headers and drops developer-token, because the access level now comes from the Cloud project behind the credentials.*

Put the client account's 10-digit customer ID in the URL, and delete the `login-customer-id` line if you sign in to that account directly. IDs go without hyphens, since `123-456-7890` returns `INVALID_CUSTOMER_ID`. With a desktop client, swap the first 2 lines for an access token from your own refresh token. If the project is still on Test and the account serves real ads, this call is where `CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION` shows up.

## Brand verification for Basic

Basic needs brand verification first, and Test and Explorer don't. Projects that already had Basic or Standard before the sunset can skip it, though Google encourages it. The steps from Google's [brand verification guide](https://developers.google.com/google-ads/api/docs/api-policy/brand-verification) (last updated October 30, 2026):

*Fig. 10: Brand verification is 2 consent screen settings and 1 button, and once it passes Google reviews a Basic application within minutes.*

1. In Cloud Console, select the project and go to APIs & Services, then OAuth consent screen.
2. On the Overview tab, click Get Started, fill in the project configuration and click Create.
3. On the Audience tab, publish to production. In a Google Workspace organization with User type Internal, click Make external, choose In production and confirm. Other accounts are External already, so click Publish app and confirm Push to Production?.
4. On the Branding tab, fill in the required fields and click Save.
5. In the top-right corner, click Verify Branding under Verification status. It takes a few minutes, and any errors come with steps to fix them.
6. When it passes, click Publish branding.
7. Back on the Google Ads API Overview page, check that no brand verification warning shows, then apply for Basic.

*Fig. 11: Brand verification runs across 3 tabs of the OAuth consent screen, and the Audience tab is where an Internal app has to become External.*

Google's documents disagree about Internal apps. Other Google Cloud pages say an Internal app, or one still in Testing, needs no brand verification, while the Google Ads guide says it "supersedes that guidance" for Basic and asks for User type External and Publishing status In production. Follow the Google Ads guide. Once you're verified and have applied, the developer token page says a Basic application "will be reviewed within minutes."

## Errors after the sunset, and the fix for each

The table lists 7 failures and what clears each one. The first 3 rows and the last 2 come from Google's developer token page (last updated October 30, 2026), including its 2 open known issues:

*Fig. 12: 3 errors from the table below, each wired to its fix, so you can match a log line to the setting behind it.*

| Symptom | Cause | Fix |
| --- | --- | --- |
| `CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION` (v25 and later) or `ACTION_NOT_PERMITTED` (v24 and earlier) | A Test project called a production account | Apply for Explorer on the Overview page |
| Explorer or Basic rejected, even after brand verification | The project is on the Free Trial, or its billing is suspended or disabled (known issue) | Upgrade to a paid tier, remove billing from the project, or apply from another brand-verified project |
| `AUTHORIZATION_ERROR` on production accounts while test accounts work | The project used a Test token before September 9 and was upgraded after it (known issue) | Google is rolling out a fix. Until then, apply for Explorer from a new project |
| Keyword ideas, reach plans or audience insights fail on Explorer | Planning services are restricted on Explorer | Apply for Basic |
| Refresh token stops working after 7 days | External consent screen left in Testing | Publish the app to In production and sign in again |
| Access gone on a project you left idle | Google revokes a project's API access after 90 days of inactivity | Apply again on the Overview page |
| Pending Basic application gone | Google closed every pending Basic application from the API Center on September 9 | Reapply from the Overview page |

The billing issue is easy to misread because the rejection email blames verification: "Basic Access requires a successfully verified OAuth brand profile." Check billing before you redo the branding steps. Removing billing turns off every other paid service in the project, so only use that workaround on a project you keep for the Google Ads API alone.

*Fig. 13: The rejection email points at brand verification even when billing is the cause, so check for a Free Trial or suspended billing first.*

## Migration checklist if you had a token

If your code ran on a token before September 9, it most likely still runs today. This list comes from the "What to do if you are an existing developer" section of Google's [developer token page](https://developers.google.com/google-ads/api/docs/api-policy/developer-token) (last updated October 30, 2026), plus 1 line from its FAQ: "Google will revoke the API access for the unused project after 90 days of inactivity."

*Fig. 14: Google's developer token page (last updated October 30, 2026) says it revokes a project's API access after 90 days of inactivity, which can catch a project that only runs a quarterly report.*

`Migration checklist`:
```markdown
- [ ] Open the Google Ads API Overview page for every Cloud project that calls the API and note its access level.
- [ ] Reapply where a project shows Test, or where a pending Basic application was closed on September 9.
- [ ] In Identity and Access Management (IAM), make the people who need Google's Mandatory Service Announcements Owners or Editors of the project.
- [ ] Update your client libraries and stop sending the developer-token header.
- [ ] For a new project, apply for access on its own Overview page. A token can't be moved to it.
- [ ] Keep each project calling the API. Google revokes a project's API access after 90 days of inactivity.
- [ ] Check the tools and MCP servers you use for a "developer token required" setting.
```

## Do you still need a manager account?

No. Google's developer token FAQ says you need a manager account "only if you need to link to and manage multiple accounts using the API." A single advertiser can give a service account, or their own Google login, access to the 1 account and call it directly.

*Fig. 15: Without a manager account you call your 1 account directly, and with one you send the manager's ID in the login-customer-id header to reach each client account under it.*

When you do go through a manager, send its 10-digit ID without hyphens in the `login-customer-id` header (`loginCustomerId` or `login_customer_id` in client library settings), and put the client account's ID in the URL. Leave the header out when you sign in to the client account directly. Test accounts still involve one: Google's quick start creates test client accounts under a test manager account.

### Adwarp after the sunset

Adwarp's Google Ads tools run on your machine, with your own Cloud project and an OAuth desktop client. The [hosted endpoint](https://adwarp.dev/docs/hosted) never registers them and serves LinkedIn Ads only.

Explorer is enough for reporting and campaign creation. `gads_search` runs read-only Google Ads Query Language, and `gads_performance` returns performance rows. `gads_launch_search_campaign` asks Google for a validateOnly dry run before it creates anything, and the campaign it creates is paused. No Adwarp tool can enable a Google campaign, so you switch it on in Google Ads yourself. [Keyword research](https://adwarp.dev/google-ads/keyword-research) needs Basic, because `gads_keyword_ideas` calls `KeywordPlanIdeaService`.

Adwarp dropped the token in version 0.5.0, published to npm on November 7, 2026 ([pull request 55](https://github.com/adwarp-dev/adwarp/pull/55)). It never sends the `developer-token` header, and [Adwarp's Google Ads setup page](https://adwarp.dev/docs/google-ads-setup) covers Cloud project access with no token. Version 0.4.0 and earlier won't start their Google tools without a `developerToken` in `~/.adwarp/google.json` or the `ADWARP_GOOGLE_DEVELOPER_TOKEN` variable, so a new user on an old version gets stopped there. `npx -y adwarp mcp` fetches the latest version. If you pinned an older one, leave the token in place until you upgrade, since Google ignores the header.

Put it to work: [Google Ads](https://adwarp.dev/google-ads). Create paused Search campaigns, research keywords and pull reports from your terminal, signed in with your own Cloud project.

## Questions

### Do I still need a Google Ads developer token?

No. Google sunset developer tokens on September 9, 2026, and access levels now belong to the Google Cloud project that owns your OAuth client or service account. The 1 exception is the App Conversion Tracking API, which still signs up for a token in the API Center.

### Will my code break if it still sends a developer token?

Not yet. Google says the header is optional and ignored by the API servers, so existing code keeps working. The same page says a future major version will reject tokens without naming which one, which is reason enough to update your client libraries and drop the header now.

### Do I need a Google Ads manager account to use the API?

No. Google's FAQ says you need one only to link and manage several accounts through the API. If you do call through a manager account, send its 10-digit ID without hyphens in the login-customer-id header.

### How do I get a Google Ads API key?

There isn't a single key. You need a Google Cloud project with the Google Ads API enabled and an approved access level, plus credentials from that project: an OAuth client that signs in as you, or a service account with a JSON key. Each request then carries an OAuth access token in the Authorization header.

### Which access level do I need for reporting, for creating campaigns and for keyword research?

Explorer covers reporting and campaign creation on production accounts, up to 2,880 operations a day. Keyword research needs Basic, because Explorer blocks KeywordPlanIdeaService and the other planning services. Standard is for tools that need more than Basic's 15,000 operations a day.

### How long do Explorer, Basic and Standard take?

Explorer is reviewed automatically and approved in most cases. Basic is reviewed within minutes once brand verification is done, while Standard goes through a manual audit that Google says typically takes 10 business days.

### Why does my project show Test access when my token had Basic?

Google moved a token's level only to projects that called the API with it in the 90 days before September 9, 2026. If the token sat unused, or you now use a different project, that project starts at Test. Apply for Explorer, then Basic, on its Google Ads API Overview page.

### What does CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION mean?

Your Cloud project has only Test access and tried to call a production account. Versions v24 and earlier return ACTION_NOT_PERMITTED for the same problem. Apply for Explorer access on the project's Google Ads API Overview page.

### Can I use my old developer token with a new Google Cloud project?

No. Google stopped moving tokens to new projects on September 9, 2026, and the token no longer decides access anyway. Apply on the new project's Google Ads API Overview page, and for Standard you can share the old token's details in the application.

### Is the Google Ads API free?

Google's access levels page and rate sheet, both last updated October 30, 2026, list no fee for API access. Limits are counted in operations a day: 1 query counts as 1 operation, and each item in a mutate counts as 1.

## Related

- [Set up Google Ads](https://adwarp.dev/docs/google-ads-setup): Adwarp's setup for the OAuth desktop client, google.json and signing in from your terminal.
- [Google Ads keyword research](https://adwarp.dev/google-ads/keyword-research): Keyword ideas, search volumes and bid ranges from your terminal, which need Basic access.
- [MCP servers for ads](https://adwarp.dev/blog/ads-mcp-servers): A guide to the MCP servers that connect an AI assistant to LinkedIn Ads and Google Ads.

Canonical page: https://adwarp.dev/blog/google-ads-api-access
Last updated: 2026-11-07