Google Ads API access and developer tokens

What a developer token actually is

Two different permissions are involved in any software touching a Google Ads account, and almost every confusion in this area comes from treating them as one thing.

• The developer token authorises the software. It is a string issued from the API Center of a Google Ads manager account, and it carries an access level and a usage quota. Sending an API request without one is refused before anything else is considered.
• OAuth credentials authorise the person. A client ID and secret identify the application to Google's sign-in, and a refresh token represents one particular user having granted that application access to the accounts their own Google login can reach.

You need both, and they fail differently. A token problem is an error about the application; an OAuth problem is an error about the user. Neither one widens what a person can do — a refresh token cannot reach an account its owner could not open in the interface, which is the property the whole security model rests on.

Test, basic and standard access

A token is issued at one of three levels, and the one you are given first is not the one that does anything useful.

An operation is not the same thing as a request, and that distinction decides whether a quota feels generous or tight. The API counts the entities you touch, so adding two hundred negative keywords in a single call is two hundred operations rather than one. Read-heavy work is metered far more kindly than write-heavy work: a report returning ten thousand rows is one request. An account being audited weekly will not come near a basic-access cap; an account synchronising bids across four hundred advertisers every hour will meet it before lunch.

Applying, and why applications fail

The mechanics are short: create a Google Ads manager account, open the API Center, and submit the form. The form asks who you are, where your tool lives, and what you intend to do with the data. Approval is not instant and not guaranteed, and the common reasons for a rejection or a round of follow-up questions are consistent:

• A vague use case. “Reporting and automation” is not a description. Name the accounts, the operations and the people who will use it.
• No visible product. A website that does not describe the tool you are applying for makes the application harder to assess than it needs to be.
• Asking for standard access first. Standard is normally granted on the evidence of what you have been doing with basic.
• A use that reads like data extraction. Anything that sounds like harvesting competitive data, or like passing account data somewhere Google's terms do not permit, will be read that way.
• Minimum functionality. If the tool will be used by advertisers other than you, Google reviews it against published requirements for what such a tool must be able to do. This catches thin wrappers.

None of this is unreasonable — it is a live API over other people's advertising budgets. It is, however, several days of elapsed time before a line of your code has talked to a real account, and it is the point at which most “connect AI to Google Ads” weekend projects quietly stop.

What else self-hosting needs

The token is one of five things. Running Google's open-source MCP server yourself means assembling all of them:

1. The developer token, at basic access or above.
2. A Google Cloud project with the Google Ads API enabled.
3. An OAuth client — a client ID and secret created in that project, with a consent screen configured.
4. A refresh token generated by signing in as the user whose access you want, plus the manager account ID if you are going through an MCC.
5. Somewhere to run it, with a Python environment and someone who notices when an API version is retired and the install stops answering.

All of which ends up in a configuration file that looks roughly like this:

# google-ads.yaml
developer_token: "YOUR_DEVELOPER_TOKEN"
client_id: "1234567890-xxxxxxxx.apps.googleusercontent.com"
client_secret: "GOCSPX-xxxxxxxxxxxxxxxx"
refresh_token: "1//xxxxxxxxxxxxxxxxxxxx"
login_customer_id: "1234567890"   # manager account, digits only
use_proto_plus: true

That file is a working credential for every account the refresh token covers. Where it lives, who can read it, and what happens when the person who generated it leaves are all questions worth answering before it exists rather than after.

The fifth item is the one people underestimate. Google retires API versions on a published schedule, and a self-hosted server pinned to a version that has been sunset does not degrade gracefully — it stops, on a date. That is the honest cost of running your own: not the afternoon it takes to set up, but the morning a year later when something that had been quietly working every day stops answering, and the person who built it has moved on.

Why a hosted connector removes all of this

AdCopilot supplies the developer token, the Cloud project and the OAuth client. What remains yours is the half that should be: you sign in with Google, grant access to the accounts you choose, and get a private connector address to paste into Claude, ChatGPT or any other MCP client. No token application, no consent screen, no YAML file, no machine.

Two consequences are worth stating plainly rather than leaving implied. The first is that the API relationship with Google is ours, not yours — our token, our quota, our obligation under the API terms. The second is that quota is shared, which is why every connector has its own rate limit: one enthusiastic session should not be able to exhaust the pool for everybody else.

When you would still want your own token

• You are building something. If your own software will talk to the API, you need your own token regardless of what connector you also use.
• You already have standard access. Many agencies do, through a manager account they have held for years. AdCopilot accepts a token you bring, so the quota and the relationship stay yours.
• Procurement requires it. Some organisations need the API terms to be between themselves and Google. That is a legitimate requirement and we would rather you met it than worked around it.
• You only want to read, and you enjoy this sort of thing. Google's server is free, Apache 2.0, and it is the same reading core AdCopilot is built on. If you are comfortable with a token and a Cloud project, run it.
• You need something no connector exposes. Offline conversion uploads, listing group trees, audience signals, bulk operations at scale. The API is much larger than any tool list; ours is thirty-six tools, of which thirty-two reach hosted connectors.

What a developer token does not give you

• It is not access to an account. The token plus a refresh token from someone with no access to an account still reaches nothing. Permissions come from Google Ads, not from the API.
• It does not change anything about your advertising. No better delivery, no different auction treatment. It is a key to a door, not a lever.
• It does not exempt you from the terms. Required minimum functionality, data-handling rules and the API terms of service apply to what you build, and they are between you and Google.
• We cannot get you one. We cannot expedite an application, appeal a rejection or lend ours for use outside our own service. If your application is stuck, Google's developer forum is the place, and being specific about your use case is what moves it.

If the point of all this was to let an assistant read your account tonight rather than next week, the audit questions worth asking first are a better use of the evening than a Cloud project. If the point was to own the plumbing, the instructions above are the whole of it, and Google's documentation is good.

Frequently asked questions