Google Ads API access and developer tokens

What a developer token was, and what replaced it

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.

• Access for the software authorises the application. Until 9 September 2026 that was the developer token, a 22-character string issued from the API Center of a Google Ads manager account. Google sunset developer tokens on that date: the access level now belongs to the Google Cloud project that owns the application's OAuth client, and a token sent with a request is optional and ignored.
• 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 project without production access gets 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, Explorer, Basic and Standard access

Access is granted to a Google Cloud project at one of four levels, and the one a new project starts on is not the one that does anything useful.

A Google Ads API 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 API 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. An AdCopilot plan counts its operations per request instead, so adding those two hundred negatives in one request uses one of your plan's daily operations (what the numbers on a plan mean).

Applying, and why applications fail

The mechanics moved with the sunset. Enabling the Google Ads API in a Google Cloud project grants Test access, and each next level is applied for from the Google Ads API Overview page in the Google Cloud console, one rung at a time. Basic needs brand verification of the project first; Standard is a manual review in which Google's compliance team asks what your tool does and who uses it. Approval is 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.
• Skipping the ladder. Each level is applied for from the one below it, so Standard is reached only from Basic, on the evidence of what you have been doing with it.
• 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.
• A programmatic proxy. Google's Ads Developer Policies prohibit a hosted interface, wrapper service, MCP server or proxy endpoint that solely replicates, wraps or re-exposes Google Ads programmatic capabilities as an intermediate layer, and they expect the users of a tool to sign in to it themselves before it changes their accounts.

None of this is unreasonable — it is a live API over other people's advertising budgets. Brand verification and a Standard review are, however, elapsed time before your code talks to real accounts at any volume, and that is the point at which most “connect AI to Google Ads” weekend projects quietly stop.

What else self-hosting needs

Access is one of four things. Running a free open-source MCP server yourself means assembling all of them:

1. A Google Cloud project with the Google Ads API enabled, at Explorer access or above to reach a real account.
2. An OAuth client — a client ID and secret created in that project, with a consent screen configured. The project that owns it is the one whose access level and quota your calls use.
3. 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.
4. 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"   # optional since the sunset; ignored
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 last 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.

Where AdCopilot fits

AdCopilot is an application built on the Google Ads API, with work of its own around the calls it makes. It connects to Google Ads through its own Google Cloud project; Google's API terms and Developer Policies apply to those calls. Each person signs in with their own Google account and grants access to the accounts they choose. You add the connector URL to Claude, ChatGPT or any other MCP client, and what that client reaches is AdCopilot's own work:

• Audits it computes itself. 18 read-only analysis tools work out their findings on AdCopilot's server — wasted spend, search terms, bidding, conversion setup, what changed in the account and why two products count results differently — and quote the numbers they measured.
• Approval, and the limits behind it. Nothing changes until you allow it in your AI client — approval is your client's own tool-permission prompt. If you tell your client to always allow a tool, it will run that tool without asking again — which is why the limits that hold either way are server-side: it cannot delete, it cannot publish a container, it will not switch on the campaign it built, and it asks for your budget before it builds.
• Your accounts, your plan. A connection can be pinned to named accounts or put on a read-only tier on request, your plan's daily operations are counted on our side, one per request, and every call is written down, refusals included.

AdCopilot connects to Google Ads through its own Google Cloud project, with your Google sign-in. If you want programmatic access to Google Ads for your own software, get your own Google Cloud account and apply for Google Ads API access there.

Two consequences are worth stating plainly rather than leaving implied. The first is that the API relationship behind AdCopilot's calls is ours — our Cloud project, our access level, our obligations under Google's terms and policies. The second is that Google's quota is our project's, which is why your plan has its own daily limit of operations and every connector its own rate limit: one enthusiastic session should not be able to exhaust it for everybody else.

When you want your own access

• You are building something. If your own software will talk to the API, it needs its own Google Cloud project with Google Ads API access, whatever connector you also use.
• Procurement requires it. Some organisations need the API terms to be between themselves and Google. That is a legitimate requirement: apply for access in your own Google Cloud project and run your own software against it.
• You only want to read, and you enjoy this sort of thing. Free open-source servers will read an account perfectly well. If you are comfortable with a Cloud project and an OAuth client, run one.
• 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 73 Google Ads tools — 55 in our fork, 18 audit tools of our own — of which 69 are exposed to a hosted connector, as of v2.45.2.

What API access does not give you

• It is not access to an account. A project with Standard access 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, the Developer Policies, 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 access. We cannot expedite an application, appeal a rejection or lend our project's access 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 have an assistant read your account tonight, the audit questions worth asking first are the place to start. If the point was to build your own software against the API, the steps above are the whole of it, and Google's documentation is good.