adlaneSign in Practical guide
Google Ads manager account access: fix API and client errors
Google Ads access has several layers. OAuth identifies and authorises the user, account permissions determine which customers that user can read, and API access also depends on the application’s developer token. A completed consent screen therefore does not guarantee a successful report, and reconnecting rarely fixes a permission or token problem.
By Adlane · Updated
Three layers of Google Ads manager account access
When account discovery fails it helps to name which layer refused. The user signed in with a Google identity; that identity holds a role on one or more Google Ads accounts; and the application making the request holds a developer token with its own access level. Each layer produces a distinct error category, and each is corrected by a different person.
| Layer | What it proves | Typical failure | Who corrects it |
|---|---|---|---|
| OAuth sign-in | The user is who they say and granted the scope | Expired or revoked grant | The user reconnects |
| Account permission | The identity can read this customer | No access, or access only through a manager | An administrator on the account |
| Developer token | The application may call the API | Token not approved for the required access level | The application owner |
| Customer selection | The request names the account that holds the data | Manager ID used where the client ID was needed | The user selects the right account |
Manager account or client account: which customer ID holds the data?
A manager account (MCC) is an umbrella for other accounts. It can list the accounts beneath it and carry access to them, but the campaigns and their performance live in the client accounts. Google explains how manager accounts link to client accounts in its help centre; the practical rule is that a report must name the client whose campaigns you want to read.
Requests made through a manager involve two IDs: the manager that grants access and the client being read. Asking for campaign data with the manager ID in the wrong role returns an error or an empty result even though sign-in succeeded. Write both IDs down before troubleshooting anything else.
Read the provider error category before reconnecting
Google returns structured error categories that distinguish an authentication problem from an authorisation problem and from a developer token problem. Preserve that category when a request fails. A tool that collapses every failure into “please reconnect” hides the information needed to fix it, and repeated consent attempts can make a token or permission problem look like a flaky login.
Reconnecting OAuth refreshes the grant for the identity. It cannot grant a role the identity does not hold on the account, and it cannot change the status of the application’s developer token. If the error names the token or the customer, reconnecting is the wrong first step.
Illustrative example: sign-in works, the report still fails
Illustrative example: a marketing lead signs in and sees a manager account that oversees four client accounts. She asks for campaign performance and receives a permission error. Her consent screen completed normally, so she reconnects twice with the same result.
The sanitised error shows that the request named the manager as the customer to read. Selecting the specific client account resolves it. In a second invented case the same error persists for one of the four clients; its administrator had removed her access the week before. Neither case was a sign-in problem.
Record IDs, operation and sanitised error, then retry small
Before asking for help, note the Google identity used, the manager and client IDs involved, the operation requested and the error category with any secrets removed. Never paste access tokens, refresh tokens or client secrets into a support message. Application configuration should be verified with the service owner, not reconstructed from screenshots.
After a correction, retry the smallest useful read: list the accessible customers, or fetch one campaign for a short date range. A small success confirms the fix before you run a broad analysis, and a small failure is easier to read than a large one.
Check manager account access in Adlane
Connect the Google Ads account in Adlane and choose the business it belongs to. Then ask a bounded question that forces a real read, for example: “List the campaigns in this account with spend for the last seven complete days.” If the read fails, Adlane shows the provider’s error category without exposing credentials, which tells you which layer to correct.
Once a small read succeeds, continue with the review you intended. Any change that follows is prepared as a proposal with the current setting and the proposed action for your approval; the conversation does not apply it, and new campaigns start paused. Access levels and developer token status remain governed by Google and the account’s administrators.