Updated 5 November 2026. Checked against Google’s current access, authentication and migration guidance. Test changes separately from a working production connection.
What does a Google Ads API integration need?
Google’s developer-token sunset guide now describes the Cloud project access model as active. Access levels transferred using API activity in the 90 days before 9 September. A previously approved but unused token does not establish that a project inherited production access.
For user authentication, check the project that owns the OAuth client ID and secret. For service-account authentication, check the project that owns the service account. Follow Google’s OAuth guide to choose the authentication route, and confirm the authorised user or service account can access the intended Ads accounts.
New signups and access upgrades belong in the project’s Google Ads API Overview in Cloud Console. The old manager-account API Center is for historical details; applications started there will not be processed. Google’s access-level guide distinguishes Test access from production-capable access and the permitted API features. Production access still has limits and does not grant unrestricted campaign authority.
The sunset guide says developer-token headers remain optional and ignored, with rejection planned for a future major version. Use a compatible client library before removing the header, and check the current migration guidance when upgrading.
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’s current migration guidance requires brand verification for new Basic and Standard access applications. Existing access holders are encouraged to verify but are not required to do so by this migration. The brand-verification guide covers the application identity and branding requirements.
Google describes automated Basic access review after verification and submission. Approval remains subject to its checks. If a verified project is rejected, review the known issues in the migration guide, including the documented Cloud billing-status issue, before changing credentials. Any billing or project change needs its own impact review.
Basic applications pending in the old API Center before the September transition were closed. Google’s migration guide tells affected applicants to reapply through the new overview page. Check the closure email 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 and later when a project with Test access tries to call a production account. Versions v24 and earlier use 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
Google’s migration guide says administrative and mandatory compliance notices are moving to Cloud project owner and editor users, with temporary continued delivery to the old API Center contact. Review both recipient lists while that transition applies.
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.
Check offline conversion uploads separately
If the integration sends qualified leads or sales back to Google, inspect its upload route as a separate dependency. Google’s offline conversion guidance describes migration of offline conversion and enhanced-conversions-for-leads uploads to the Data Manager API from 15 June 2026, with legacy Google Ads API access restricted. A working reporting request does not prove that a new upload integration can use the same API. Check the vendor’s supported route and reconcile accepted outcomes. Our offline conversion timing guide explains the reporting checks after delivery.
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.
How we can help
Our Google Ads management and account reviews connect campaign goals with the reports and conversion signals the business needs. When the integration serves your sales process, our ConvertX CRM service can help scope ownership, delivery checks and rules-based follow-up. Bring the failing report or error and the workflow it affects. We agree the access and tests before changing anything, then assess measurement against closed deals and money received. Keep passwords, tokens and private keys out of the initial enquiry.
