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

Google sunset Google Ads API developer tokens 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.

Here's the change row by row, from Google's developer token page (last updated October 30, 2026):

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 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:

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 and developer token page (both last updated October 30, 2026) give the limits and the review times:

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.

"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 (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.

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 (last updated November 4, 2026) and the developer token FAQ:

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.

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 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 (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 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.

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:

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"}'

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 (last updated October 30, 2026):

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.

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:

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.

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 (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."

- [ ] 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.

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.

By Stan Rymkiewicz, maintainer of adwarp. Published November 7, 2026.