Published May 25, 2026

How to Get Your Google Ads API Key

May 25, 2026

Google Ads doesn't have a single API key; API access is four credentials spread across two consoles—a developer token from your Google Ads manager account, plus an OAuth client ID, client secret, and refresh token from Google Cloud. And the developer token starts in a Test tier: everything works against test accounts, but production calls hard-fail with a clear "test-only" error until you apply for an upgrade—which is where most teams get stuck.

This guide walks through all four credentials in order, explains the developer-token tiers that trip people up, and covers the login-customer-id nuance you'll hit the moment you manage client accounts.

Key takeaways

There's no Google Ads "API key." You need four things: a developer token, an OAuth client ID and secret, and a refresh token.
The developer token lives in your Google Ads manager (MCC) account; the OAuth credentials live in Google Cloud Console. Two separate consoles—a frequent source of confusion.
The developer token starts at Test Account access and cannot touch real, spending accounts. You must apply for Basic (then optionally Standard) access, which Google reviews.
When a manager account accesses client accounts, you must send login-customer-id (the manager's ID) alongside the target customer_id, or calls fail with permission errors.

Before you start

You need a Google Ads manager account (MCC)—not just a regular ads account. The developer token is issued at the manager level, and the manager is your API "login" context. If you don't have one, you can create it from the manager-accounts page in Google Ads in about a minute.

The mental model: four credentials, two consoles

Before the steps, hold this picture—it prevents most of the confusion:

Google Ads console (your manager/MCC account):

Developer token — identifies your app to the Google Ads API; required on every call.
login-customer-id — the manager account ID you use as the login context when reaching child accounts.

Google Cloud Console (an API project):

OAuth client ID and secret — identify your app to Google's OAuth server.
Refresh token — what your backend stores to mint access tokens.

That's literally what "four credentials across two consoles" means. Now the steps.

Step 1: Get your developer token (Google Ads → API Center)

Sign in to your Google Ads manager account at ads.google.com.
In the left nav, go to Admin, then API Center.
Fill out the form: API contact email, company name and type, intended use, and country.
Submit. A developer token is generated for that manager account.

Your token starts at Test Account access—usable immediately, but only against test accounts.

Step 2: Set up OAuth credentials (Google Cloud Console)

This is the second console, and the part people forget is separate from Google Ads.

Create a project. In Google Cloud Console, open the project dropdown → New project → name it → create.
Enable the API. Go to APIs & Services → Library, search Google Ads API, and click Enable.
Configure the OAuth consent screen. Under APIs & Services → OAuth consent screen, choose External or Internal, fill in the app name and support emails, and on the scopes step add the Google Ads scope: https://www.googleapis.com/auth/adwords. Publish the app when you're ready to move from Testing to Production.
Create credentials. Go to APIs & Services → Credentials → Create credentials → OAuth client ID. Choose the application type (Web application or Desktop app); for web apps, set your authorized redirect URI. Copy the client ID and client secret.

Step 3: Get a refresh token

Using your OAuth client ID and secret, run an OAuth flow (Google's client libraries for Python, Node, and others ship example auth scripts) that opens a browser consent and outputs a refresh token. Your backend stores this and exchanges it for short-lived access tokens on each run.

With the developer token, OAuth client ID/secret, and refresh token in place, you can call the API. Two headers matter when a manager account operates on client accounts:

customer_id — the Google Ads account you're reading or modifying (the child account).
login-customer-id — the manager account that has access to it, in 8–10 digit format with no dashes.

If you omit login-customer-id, or set it to the client instead of the manager, calls fail with USER_PERMISSION_DENIED ("User doesn't have permission to access customer")—even when everything looks correctly linked. This is one of the most common post-setup errors.

The gotcha that blocks production (read this before you build)

Here's the failure pattern that shows up constantly: a team signs up, gets a developer token, wires all four credentials, builds the integration, and everything works against a test account. Then they switch customer_id to a real, spending account—and every request fails with "The developer token is only approved for use with test accounts. To access non-test accounts, apply for Basic or Standard access."

A fresh developer token is Test Account access only. To touch production you must apply—directly in the API Center—to upgrade:

Basic access: up to roughly 15,000 operations/day across most services (as documented at the time of writing); suitable for smaller products and early production.
Standard access: effectively unlimited daily operations for most services; for large or commercial products. Standard approval ties to Google's permissible-use guidelines and, for some categories, Required Minimum Functionality.

Apply for the upgrade early, not after you've built everything—because of the review wait, which is measured in weeks, not days. As of early 2026, Google has acknowledged a backlog and longer review times on developer-token applications, with tightened checks that include advertiser verification for one or more accounts under the manager account you applied from. Treat the upgrade as a real timeline item.

Keeping your credentials secure

Client secret and refresh token are server-side only—never in client code or a public repo. Store them in environment variables or a secrets manager.
Use one Google Cloud project for your Google Ads OAuth client, and configure that project's client ID/secret consistently in your app alongside the developer token. The developer token itself is tied to your Ads manager account, not a Cloud project—but mixing credentials from multiple Cloud projects in your app config is a common cause of auth confusion.
Store tokens per customer (refresh token, scope, expiry, the authorizing account) mapped to your workspace, and refresh proactively so scheduled jobs don't break.

Frequently asked questions

What's my Google Ads API key? There isn't one. You need a developer token (from your Google Ads manager account's API Center) plus OAuth credentials—client ID, client secret, and a refresh token—from Google Cloud Console.

Why does my integration work in test but fail on real accounts? Your developer token is at Test Account access. Apply for Basic (or Standard) access in the API Center to call production accounts—and expect a review wait.

What's login-customer-id for? When your manager account accesses a client account, login-customer-id is the manager's ID (no dashes) and customer_id is the child account. Omitting it causes permission errors.

What OAuth scope do I request? https://www.googleapis.com/auth/adwords.

Do I need a manager (MCC) account? Yes—it's where the developer token is issued and the recommended account for centralizing API access.

Connecting Google Ads alongside your other ad platforms

Four credentials across two consoles, a tiered token with a review queue, and the login-customer-id nuance—that's the setup for one ad platform. Repeat it for each: LinkedIn requires a vetted app and 3-legged OAuth; Meta needs an app, access token, and business verification. Every platform has its own object model and reporting semantics on top.

Unified.to collapses that into one integration. Unified provides Google Ads through its normalized Advertising API—working with ad accounts (organizations), campaigns, groups, ads, creatives, targeting, and performance reports as consistent objects—alongside LinkedIn, Meta Ads, TikTok Ads, Amazon Advertising, and Microsoft Advertising, across one connection model. You pull cross-platform performance from a single endpoint (GET /ads/{connection_id}/report) with normalized KPI selectors, and read/write campaign controls without per-platform branching. Unified manages each platform's authorization—including Google's OAuth—so you handle credentials and token refresh in one place, not across a dozen consoles.

It's the same pattern that lets teams like Humi ship integrations in days rather than building each one in-house: integrate once per category, and get every platform in it.

→ Start your 30-day free trial

→ Book a demo

All articles