Google Ads API Basic Access: How a Small SaaS Got Approved in Two Days

Google approved our Ads API Basic Access application in two days. Our Ads integration stayed dead for six more.

Both facts taught me something. The approval taught me what Google's compliance team wants to see in an application. The six dead days taught me that approval and a working integration are separate problems, and the second one is yours alone.

Savra is a marketing platform that reads a customer's own Google Ads performance into dashboards and an AI assistant. Reporting only. That one sentence, held consistently across the application, the code, and the privacy policy, is most of why the approval came back fast.

What is the Google Ads API access ladder?

Every request to the Google Ads API carries a developer token, and the token's access level decides what it may touch.

The Explorer tier changed the math for small products. Before it existed, a pending Basic application blocked your launch. Now a fresh token that lands at Explorer can serve real reporting for early customers while the Basic application sits in the queue, and Basic becomes headroom rather than a gate.

One warning before anything else: the API Center page in your manager account has a Reset token button. It invalidates the current token the moment you press it. There is no situation during an application where pressing it helps you.

What did the approved application say?

The form asks what your company does, what your tool does, and which API capabilities you plan to use. Three choices shaped ours.

We claimed less than the API offers. The capabilities section lets you tick campaign creation, management, keyword planning, and reporting. Our code runs three GAQL reporting queries and an account list. So we ticked reporting and nothing else, and the approval email came back scoped to precisely that: "Your tool provides reporting data, but does not allow users to create or manage campaigns." Reviewers approve what they can verify. Every capability you claim is a claim they have to check against your product, and a capability your product does not show is a reason to slow down or reject.

We matched the Cloud project to the OAuth client. The application asks for a Google Cloud project number. We used the project that owns the OAuth client our users actually consent through, so the reviewer sees one coherent identity: the consent screen, the API calls, and the application all point at the same project.

We attached proof the tool exists. The form accepts a design document. Ours was six pages: what Savra is, the exact GAQL queries, data flow, storage, and five screenshots of the live product's reporting dashboards for a real account. Screenshots of a working product answer the reviewer's central question, which is whether the tool described is a tool that exists.

Two structural details mattered before the form was ever filled in. The developer token lives in a manager account (MCC) created for the product, under the product's own domain email. Our older agency manager account had a legacy test-tier token from before the Explorer rollout; tokens keep the access level they were born with, so we left it alone and minted a fresh one. And we brand-verified the Cloud project first, because the application form itself says brand verification expedites review.

What do the three developer-token errors actually mean?

We met all three within one week, and they mean three different things.

DEVELOPER_TOKEN_INVALID means the token string in your environment is wrong, not pending. We burned days treating this as an approval problem when the real cause was a stale value in production config.

DEVELOPER_TOKEN_NOT_APPROVED means the string is right and the access level is not there yet. This is the healthy waiting state. When we swapped the correct token in, INVALID became NOT_APPROVED, and that transition told us the remaining work was Google's, not ours.

A version error after approval means your client is calling a retired API version. More on that below, because it cost us the six days.

One operations note that applies beyond Google: if your service reads config through a process manager like systemd with an EnvironmentFile, those values load at process start and win over any dotenv file your framework reads. A graceful reload that re-executes workers does not re-read them. We updated the token on disk, reloaded, verified nothing, and the workers kept serving the old value until a full restart. Credential changes get a restart, always.

Why did the integration stay dead after approval?

The approval email arrived on August 4. On August 10 our production logs still showed every Ads call failing.

The token was correct. The access level was granted. The code pinned Google Ads API v21, and Google had sunset v21 in the meantime. A sunset version rejects every request regardless of your token's privileges. Authentication succeeded and the request died anyway.

The fix was a one-line version bump to v24, the newest version our installed client library shipped. Within the hour, the same call that had failed all week listed twelve accessible customer accounts.

The lesson generalizes. The Google Ads API retires versions on a published schedule, roughly every few months, and your client library only speaks the versions it shipped with. So an approval, a correct token, and untouched code can still add up to a dead integration if the pin aged out while you waited. Put the sunset schedule on your calendar the day you pin a version, and check which versions your library supports before you assume the pin is the ceiling.

What would I tell someone applying this week?

Ask for the narrowest capability set your code demonstrates. Put the application under a manager account and Cloud project that share your product's identity. Brand-verify the project first. Attach screenshots of the live product doing the thing you describe. Read your error codes as three different diagnoses instead of one vague "not approved yet." And the day the approval lands, check your API version pin before you celebrate, because Google kept deprecating while you were in the queue.

FAQ

How long does Basic Access approval take?
Google quotes several business days and acknowledged a backlog in early 2026. Ours took two days on a brand-verified project. Treat the Explorer tier as your bridge so the wait blocks nothing.

Can I skip the application entirely?
If your token landed at Explorer and you only run reporting for a small number of accounts, yes, for a while. Watch the 2,880 daily operation ceiling and apply for Basic before growth makes it a problem.

What belongs in the design document?
What the product is, the exact queries or mutations you run, where the data goes, and screenshots of the live product. A reviewer who can see the tool working has less to doubt.

My token is approved and calls still fail. What now?
Confirm the running process actually holds the new token (full restart, not reload), then check the API version your client targets against Google's sunset schedule. Both failures wear disguises that look like approval problems.