Google Ads API developer tokens were sunset on September 9, 2026. The current Google guide says API access levels now belong to the Google Cloud project used by the OAuth client or service account. Existing code may keep sending the token for now, but Google says the header is optional and ignored by API servers, and a future major version will reject it.
Use the Cloud Console for new access
For new Google Ads API access, use the Google Ads API Overview in Google Cloud Console. Google explicitly says applications started in the Google Ads manager account’s API Center will not be processed for this transition. The old API Center remains useful for historical developer details, but not for applying for or managing current access levels.
A manager account is no longer required to use the API. You still need one when the integration must link to and manage multiple customer accounts through the API.
Keep four objects separate
| Object | What it controls | Check |
|---|---|---|
| Google Cloud project | Current API access level and ownership of OAuth credentials | Open Google Ads API Overview and confirm the project ID and level |
| OAuth client or service account | Authentication path and the project that receives access | Map the credential to the same project used in the API request |
| Developer token | Historical access record during the transition; no longer the access-level owner | Stop treating its API Center level as the current project state |
| Manager account | Optional account-linking and multi-account management layer | Use it only when the account hierarchy requires it |
Access levels and verification
Google continues to enforce Test Account, Basic and Standard access levels, but the level is now enforced at the Cloud-project boundary. For new Basic and Standard applications, brand verification is required. Google says Basic applications are now automated and reviewed within minutes after verification and submission; Standard access still involves manual review. Existing holders do not have to repeat brand verification, although Google encourages it.
Google also says approved developer-token access was transferred only to Cloud projects identified from API activity in the previous 90 days. A new project, or a project that never used the token, defaults to Test Account access until the owner applies for the appropriate level.
Migration checklist
- Inventory every application, OAuth client or service account, Cloud project, customer account and manager-account link.
- For each project, record the access level shown in Google Cloud Console and the credential that uses it.
- Complete brand verification before a new Basic or Standard request.
- Test the integration against a test account, then make one controlled production read request only after the project level is approved.
- Upgrade the client library if necessary and remove the developer-token header on a planned release; do not remove it blindly from a live integration without checking the library’s current support.
- Move mandatory administrative contacts from the old API Center record to the Cloud-project owner/editor list.
Failure cases to put in the runbook
CLOUD_appears in API v25 when a Test Account project calls a production account. Older API versions can returnPROJECT_ NOT_ APPROVED_ FOR_ PRODUCTION ACTION_. Apply for Explorer or the appropriate access from the Cloud project’s Google Ads API Overview page.NOT_ PERMITTED - Pending Basic applications started in the old API Center are closed; reapply from Cloud Console. Pending Standard applications as of September 9 continue through review.
- An approved token cannot simply be reassociated with a new Cloud project after the sunset. Apply for access for the new project.
- Unused projects can lose access after 90 days of inactivity. Store an owner and review date with the project record.
What success looks like
The migration is complete when the project, credential, access level, customer-account path and owner are documented; a test request succeeds; and production access is verified from Cloud Console rather than inferred from an old developer-token record. This is an implementation checklist, not an account approval or a guarantee of quota.
Map projects before a cutover
The difficult part is not deleting a header from source code. It is proving which Cloud project owns the access level used by each credential.
| Observed situation | What to record | Decision |
|---|---|---|
| Project used the token during the previous 90 days | Project ID, credential, customer accounts, access level and owner shown in Cloud Console | Verify the transferred level, then test the existing integration |
| New project or no recent API activity | Project ID, intended customer path, brand-verification state and requested level | Expect Test Account until the owner applies from the Google Ads API Overview |
| One manager controls several customers | Manager customer ID, linked accounts, OAuth project and service identity | Keep the manager layer; it is an account-linking requirement, not the access-level owner |
| One integration serves one customer | Customer ID, project, credential and production test evidence | Do not add a manager account merely because the old setup used one |
Use a staged release sequence
- Freeze a copy of the current library version, token handling and customer-account map. Do not change credentials while the inventory is incomplete.
- Create or select the Cloud project and assign an owner/editor who can receive Google Ads API notifications. Confirm that the OAuth client or service account belongs to that project.
- Open the Google Ads API Overview, record the displayed access level, complete brand verification where required and save the request timestamp.
- Run a read-only test against a test account. Capture the project ID, customer ID, API version, request type, response and any error code.
- Promote one production read request only after the project level is approved and the owner has reviewed the customer-account path. Then schedule the library/header change.
- After the release, check a second request and the project’s owner/contact record. A successful first request does not prove every customer link or write operation is valid.
When the migration should stop
CLOUD_means the project state must be fixed; it is not solved by retrying with an old token.PROJECT_ NOT_ APPROVED_ FOR_ PRODUCTION - A pending Basic application from the old API Center is closed for this transition. Start again in Cloud Console rather than waiting on a stale request.
- Moving a credential to a new project can change the access boundary. Treat that as a new application and record the new project owner.
- If a customer request succeeds but reporting totals do not reconcile, stop the migration and check account hierarchy, currency and date boundaries before changing measurement logic.
Use DMT’s Google Ads API version migration page for version and deadline context, the Developer Assistant page for assisted implementation context, and the measurement-stack guide when the API feeds marketing reporting. None of those owners replaces Google’s current access policy.
FAQ: questions readers ask
- Do I need a manager account to use the Google Ads API?
- Not for a single-account integration. Google says a manager account is still needed when the application links to and manages multiple customer accounts.
- What replaced the developer token’s access-level role?
- The Cloud project used by the OAuth client or service account now owns the access level. Keep the token in the transition record, but verify the project state in Cloud Console.
- Why did a previously working project fall back to Test Account?
- Google says projects without qualifying API activity in the previous 90 days may not inherit the prior approval. Check the project and apply for the required level from the new onboarding path.
Source note: Dates, access levels, error names, verification requirements and manager-account rules are taken from Google’s developer guide updated September 10, 2026. No Google account was changed or tested for this article.
Sources: Google Ads API developer-token guide Google Ads API getting started
