Google is moving Google Ads API onboarding and access management into Google Cloud projects. Existing integrations are not automatically broken: Google's announcement says active access is transferred using recent activity and existing code can continue working. The immediate task is to verify the correct project, access level and responsible owners.
This matters to businesses relying on automated reports, CRM connections or campaign-management tools. The person who owns the advertising account may not be the person who controls the Cloud project behind an integration.
Reviewed 20 September 2026 against Google's 10 September developer announcement. This is an ownership and verification checklist, not an instruction to change credentials in a live system without testing.
What changed in the access model?
Google's official announcement describes a new API overview and onboarding experience in Google Cloud Console. New onboarding no longer requires a Google Ads manager account merely to sign up for API access.
It also says API access levels are now associated with the Cloud project used to generate the OAuth credentials. Active developer-token access is automatically transferred to projects based on recent API activity. During this transition, developer-token headers can still be sent, but are described as optional and ignored by the API servers.
Google encourages code updates to stop sending developer tokens and says a future major API version will reject them. That is a future compatibility requirement, not evidence that all existing calls must fail today.
OAuth authorisation and permission to access the relevant advertising account still matter. A change in API access management should not be interpreted as removing the need for proper account access or secure authentication.
What should an existing integration owner verify?
Create an inventory before editing anything. For each integration, record its business purpose, operator, Cloud project, OAuth configuration owner, API version and whether it reads data or can make changes. Record identifiers in an access-controlled operational document, not a public article or screenshot.
Then compare the previous developer-token access level with the project's current Google Ads API access level, following Google's guidance. If the levels do not match, investigate the specific project and use the documented application or support route.
Do not create a new Cloud project merely because the interface has moved. An unnecessary replacement can create new approval, ownership and credential-management work. First establish whether the existing project has the expected access.
For third-party software, ask the vendor which project and permissions it uses. Do not request its private credentials. Your business needs clarity about responsibility and access, not copies of secrets it should not hold.
What changes for new Basic or Standard applicants?
Google says new Basic and Standard access applications require brand verification for the Cloud project. Existing access holders are not required to complete that verification under the announcement, although Google encourages it.
The announcement also describes automated Basic access review after verification and submission. “Automated” does not mean every application is approved, and a published review expectation is not a service guarantee from D4J.
Pending Basic access applications are subject to a one-time closure during the transition. Google says affected applicants should receive email information and reapply through the new overview page. If an application was closed, determine whether that is the reason before treating it as a permanent rejection of the business.
Keep the application description consistent with the actual tool. Explain what it does, who uses it and which account data or actions it requires. Do not overstate functionality to obtain access.
How should you interpret production-access errors?
Google identifies CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION for API v25 when a project with Test Account Access tries to call a production account. Older versions may report ACTION_NOT_PERMITTED for that situation.
Those messages should lead to a project-and-access check, not repeated credential rotation. Google advises applying for Explorer Access through the project's API overview where appropriate. Confirm the current instructions for your version and use case.
A test environment can establish that code is syntactically valid while still lacking production access. Conversely, production access does not establish that the code is authorised to make every possible account change. Keep access level, account permissions and application behaviour separate in the investigation.
Check ownership and notification recipients
The announcement says Mandatory Service Announcements will be sent to relevant Cloud project owner and editor email addresses. Review whether those recipients are current and monitored.
Do not grant broad Owner or Editor access to everyone merely to distribute notifications. Review existing role assignments, preserve least privilege and arrange an appropriate internal handover for operational notices. Departed staff, unmonitored shared addresses and a single unavailable contractor are continuity risks.
Document who approves credential changes, who can revoke access and who responds when reporting stops. A business-critical integration should not rely entirely on one person's memory.
Test safely before changing a working connection
Start with a read-only request suited to the integration, verify the intended account and inspect the returned result. Keep secrets out of logs. A successful request should be traceable to the expected project and account, not merely to some valid credential found on the machine.
If code changes are required, test them in an isolated environment and review the dependency and API-version requirements. Preserve a recovery path. Do not use a campaign mutation, real enquiry or customer transaction as an informal connectivity test.
For scheduled reporting, verify the next actual output and its data coverage. An HTTP success with an empty or wrong-account report is not a working business deliverable. For integrations that upload outcomes, also verify acceptance and error handling without inventing test sales.
A useful handover checklist
The work is complete when the responsible team can identify the project, explain its access level, locate the current documentation, receive notices and demonstrate the integration's intended result. Record unresolved approval or vendor dependencies honestly.
Our custom programming and integrations scope covers bounded integration work. If a CRM connection is failing, the GoHighLevel audit and repair service may be the more appropriate starting point.
Describe the affected report or workflow, its operator and the observed error through the existing Discuss project form. Do not paste passwords, tokens or private keys into the form. Secure access should be arranged separately when required.
