The first time I tried to get Google Ads API access working, I spent two hours on YouTube before I even understood what I was looking at. Then another two hours actually doing it. Four hours on my first try.

The scripts and tutorials I found assumed I already knew the Google Cloud Console. I didn’t. None of the vocabulary was familiar. OAuth consent screens, test users, scopes, refresh tokens, a developer token that lives somewhere completely different from the Cloud project. Every tab I clicked produced three new tabs I also had to understand. I almost gave up more than once.

I came back to it three separate times over a few months before I finally had a working google-ads.yaml file and a test script that pulled a clean list of accounts. When that test script printed my MCC accounts for the first time, it was a whole new world. Suddenly Claude Code wasn’t just a writing tool. It was something that could reach into my actual accounts and do real work. Queries I would have spent an hour building in the UI took seconds. Audits that were just ideas became agents.

The four-hour setup is also the thing that stops most PPC operators cold. I’ve watched it happen in my own circle, and it’s the single most common reason I hear when someone says they “couldn’t get AI working for PPC.” Not a model issue. Not a skill issue. They couldn’t get the API connection to work.

If the one skill that unlocks every other AI agent in my stack is also the one skill that makes most PPC operators quit before they start, how do I make the setup repeatable without the four hours of rabbit holes?

That question is what the google-ads-api-setup skill exists to answer. It’s the prerequisite for every other skill in my PPC AI Skills repo. Mutation safety, the SQR classifier, impression share diagnostics, all of them depend on this one piece. If the API isn’t connected, nothing downstream runs.

It’s also the first skill I recommend anyone start with, regardless of their AI experience. Get this working, and the rest of the stack opens up. Don’t, and AI in PPC stays a demo rather than a system.

Here’s what the skill covers, why the standard Google documentation doesn’t fix the problem, and what actually matters if you want to cross this bridge today.

Get the Google Ads API Setup skill → github.com/fourteenwm/ppc-ai-skills/google-ads-api-setup

Free and open-sourced. The repo has the step-by-step README, a credential generator script, and an example YAML template. About 30 minutes of setup the first time you do it.

The Core Problem: The Setup Tax No Tutorial Explains

The Google Cloud Console was built for software engineers. Google Ads is used by marketers. The bridge between them, the API setup, has always been brutal because nobody who writes those docs remembers what it’s like to not already know what the Cloud Console is.

This shows up in small ways that add up fast. You don’t know which sidebar menu has OAuth. You don’t know that “Google Ads” and “Google Ads API” are two different things in the API library. You don’t know that your developer token lives inside Google Ads, not inside Google Cloud. You don’t know that login_customer_id wants digits with no dashes. Every step is a small unfamiliarity that gets compounded when you don’t have a map.

The standard Google documentation doesn’t fix this because it assumes you already know the platform. The YouTube tutorials don’t fix it either. Most are five minutes of clicking with no explanation of what you’re clicking or why.

What actually works is a walkthrough that names the traps, tells you which interface you’re in at every step, and shows you the common error messages before you see them.

That’s what this skill is.

You Need the MCC, Not Just an Account

The first fork in the road nobody tells you about: developer tokens are issued to Manager (MCC) accounts, not individual Google Ads advertiser accounts.

If you’re a solo operator running a single Google Ads account, you might not even have an MCC set up. You’ll click into API Center expecting the developer token to be there, and it won’t. The fix is to create an MCC first, link your advertiser account to it, and then come back to API Center.

This is the reason a lot of solo operators give up. They think the API is just unavailable to them. It isn’t. The extra step of spinning up an MCC takes ten minutes, and it’s the unlock that makes every downstream skill possible.

Once the MCC exists, the developer token shows up in API Center under the wrench icon. That token belongs to the MCC, not your personal Google account. If you ever switch to a different MCC, you need a different developer token.

The Three Credentials That Have to Agree

This is the part that makes the OAuth flow feel like juggling.

Three separate credentials all have to line up, and they come from three different places:

  1. Client ID and Client Secret. Generated when you create OAuth client credentials in the Google Cloud Console. Come as a downloaded JSON file.
  2. Developer Token. Lives in the Google Ads MCC under API Center. Has nothing to do with the Cloud Console.
  3. Refresh Token. Generated by running a Python script that uses credentials 1 and 2 to walk through the OAuth flow in your browser.

When any one of these is wrong, the error message you get is almost always cryptic. “Request had invalid authentication credentials” doesn’t tell you which credential failed. “invalid_grant” doesn’t tell you whether the token expired or the Client ID has a typo. The only way to debug is to verify each one independently, which is why the skill’s test script exists. It isolates the failure.

The mental model that helped me: think of it as a three-legged stool. All three legs have to be solid or the whole thing falls over. Most setup failures are one leg being slightly off. Fix that leg, and the stool stands.

The Test Users Step Eats More People Than Any Other

This is the single most common point where people abandon setup entirely.

During OAuth Consent Screen configuration, there’s a step called “Test Users.” You have to explicitly add your own email address to this list. If you skip it, the OAuth flow later produces this error:

Access blocked: This app’s request is invalid

No hint about Test Users. No suggestion to add yourself. Just “blocked.” People see this and assume they did something wrong at a much earlier step, so they start over from Step 1. Still fails. Start over again. Give up.

The fix is a single click that takes ten seconds. You just have to know the step exists.

The other version of this failure mode is choosing “Internal” instead of “External” on the consent screen. Internal only works if you’re on a Google Workspace organization, and most solo operators aren’t. But “Internal” sounds more secure, so people pick it, and nothing works. Choose External. Even if it’s just you.

Once It Works, Back Up the YAML and Don’t Touch It

Refresh tokens don’t last forever. They can be revoked if you change your Google password, if the app goes too long without use, or if Google decides to invalidate them in a security cleanup. When that happens, you’re back at the refresh token step generating a new one.

Most of the time, that’s fine. What isn’t fine is losing the google-ads.yaml file itself. That file has your login_customer_id, your developer token, your client secrets, and your refresh token. All the pieces that took four hours to assemble the first time. Lose it, and you’re rebuilding from scratch.

What I do now: once the YAML is working and the test script pulls accounts cleanly, I copy the file to a secure location outside the project directory. It goes in my password manager along with a note on which MCC it belongs to. If a refresh token eventually gets revoked, I only have to regenerate that one piece, not the whole config.

The other rule: never commit the YAML to git. Ever. It’s as sensitive as a password. The skill’s example file is called google-ads.example.yaml for a reason. The real file always stays local, always stays in .gitignore, always stays out of any shared repo.

What This Has Actually Unblocked

Once the API connection works, the dominoes fall fast:

  • Querying account data in seconds. Anything you’d previously export from the Google Ads UI, you can pull with a GAQL query in a second or two. Search terms, keywords, conversion actions, audit reports, budget vs. spend, asset performance. All of it.
  • Running skills across accounts, not just one at a time. Without the API you’re stuck doing things account-by-account in the UI. With it, a single script loops through a hundred accounts and reports what needs attention.
  • Automating the things you already know need to be automated. Pacing checks, budget audits, negative keyword uploads, RSA asset refreshes, conversion tracking health scans. All of it moves from “someday” to “this weekend.”
  • Unlocking every other PPC AI skill. Mutation safety, the SQR classifier, impression share diagnostics, none of them matter if the API connection isn’t working. Get this one right, and every downstream skill becomes usable.

The return on investment isn’t subtle. Four hours of painful setup against hundreds of hours saved over the lifetime of the connection. I’ve used mine for years. It’s still the same YAML file.

Get the Google Ads API Setup Skill

Start in 30 minutes

→ Get the setup guide on GitHub

The repo includes the step-by-step README, a Python script that generates your refresh token, and an example YAML template:

git clone https://github.com/fourteenwm/ppc-ai-skills.git
cd ppc-ai-skills/google-ads-api-setup
pip install google-ads google-auth google-auth-oauthlib google-auth-httplib2 pyyaml

Follow the README one step at a time. The whole setup takes about 30 minutes the first time you do it, assuming you already have an MCC account. Once it’s working, every other skill in the repo runs against the same google-ads.yaml file.

Free. Open-sourced. MIT licensed.

The full repo has nine other PPC AI skills I use in production every day. Mutation safety, GAQL query patterns, impression share diagnostics, ad copy verification, SQR classification, and more. All at github.com/fourteenwm/ppc-ai-skills.

The Bigger Point

The reason I can run 118 accounts with 22 AI agents isn’t clever prompting. It’s that the API connection works, and every skill in the stack depends on it. Without this one piece, everything upstream is theory.

Most PPC operators who bounce off AI bounce off it at this step. Not at the model. Not at the skills. At the setup. They spend two hours trying to make the Cloud Console cooperate, hit the Test Users error, conclude that AI automation isn’t for them, and walk away.

That conclusion is wrong. The setup is bad, not the automation. Once you’re through it, you don’t go back. The connection keeps working, and every new skill you add just slots into the same pipe.

Set it up once. Back it up. Never set it up again.