Google Ads API Access in 2026: Developer Token Sunset, Cloud Console Onboarding and Brand Verification
On 9 September 2026 Google stopped issuing developer tokens for the Google Ads API. This is not cosmetic. Google Ads API access is no longer tied to a token you once requested through a manager account — it is determined by the Google Cloud project that issued your OAuth credentials. In parallel, API version v22 shuts off on 7 October 2026, and brand verification is now mandatory for new Basic and Standard applications.
Here is what actually changed, how access is granted and kept today, which mistakes teams hit during migration, and what to do if your integration still runs on the old version and you are reading this days before the cutoff.
How Google Ads API access works now: from token to project
The old model: you applied from a manager account, received a developer token, the access level lived on the token, and the Cloud project was an OAuth implementation detail. That relationship has been inverted.
- Developer tokens are no longer issued. Existing tokens are still accepted in calls, but they have become optional.
- Access level is determined by the Cloud project that issued your OAuth credentials — for user authentication and service accounts alike.
- Sign-up moved to the Google Cloud Console. New developers no longer need a Google Ads manager account to apply.
- Brand verification is required for new Basic and Standard applications.
- Project inactivity beyond 90 days costs you access.
The practical consequence: the Cloud project stopped being a wrapper and became the unit of access ownership. Whoever owns the project owns the integration.
The three access tiers in practice
| Tier | Purpose | How it is granted | What to watch |
|---|---|---|---|
| Test | Development and debugging against test accounts | Available immediately | No production accounts — test environment only |
| Basic | Production accounts at limited operation volume | Automated review, fast turnaround | Project brand verification required |
| Standard | High operation volume, commercial integrations | Manual review | Prepare a clear product and use-case description |
The classic planning mistake is budgeting time for engineering and none for review. Basic goes through automated review and rarely blocks a project. Standard is reviewed by humans and can take days. If an internal reporting system has a launch date, the Standard application does not get submitted in the final week.
Brand verification: what to prepare
Verification is attached to the Cloud project and its OAuth consent screen. In practice: a domain you demonstrably control, a properly completed consent screen, a product name that matches your brand, and working links to a privacy policy and terms of service. Mismatches between project name, domain and company name on the paperwork are the most common reason for an extra round trip.
Existing access holders are exempt but encouraged to verify. The sensible move is to do it calmly in advance rather than on the day you need to raise your access tier.
How to apply, step by step
For a team starting from zero, the sequence looks like this. Steps 1–4 take a developer about an hour; steps 5–7 need whoever owns the brand and the legal pages.
- Create a project in the Google Cloud Console. Name it the way you name the product publicly — that is the first thing reviewers compare.
- Enable the Google Ads API in that project’s API library. A common slip is enabling the API in one project and issuing credentials from another.
- Configure the OAuth consent screen. Domain, a contact address on your corporate domain, links to a privacy policy and terms of service.
- Issue credentials — an OAuth client for user authentication, or a service account if the integration runs unattended.
- Apply for the access tier you need from that same project.
- Complete brand verification for the project; it is mandatory for new Basic and Standard applications.
- Document which project belongs to which integration and who owns it.
The most frequent rejection on this path is not technical but editorial: the description does not make clear what the product does or why it needs advertising data. Write it the way you would explain it to a client — what problem it solves, whose accounts it touches, which operations it performs.
OAuth or service account
| Scenario | Choose | Why |
|---|---|---|
| Internal reporting export across your own accounts | OAuth with a refresh token on a technical identity | Simpler to set up, no org-level delegation required |
| A product that connects client accounts | OAuth with explicit client consent | The client sees what they grant and can revoke it |
| Background jobs inside your own infrastructure | Service account | No dependency on a human user and their password |
One rule applies to both: the identity behind the refresh token must not belong to an individual employee. Nobody’s resignation should stop the bidder.
The 90-day rule: access that disappears quietly
A project that makes no calls loses access to inactivity. Two scenarios suffer. The first is the “spare project just in case” — it quietly expires, and the day you need a fallback there is no fallback. The second is seasonal integrations: an export that only runs during peak season can greet you next season with a refusal.
The defence is trivial: keep a light periodic call in the project — a weekly metadata request, for example — and monitor it like any other production job. That is cheaper than repeating review.
The v22 sunset and living with versions
Google Ads API versions live roughly a year and are retired on schedule: v22 stops working on 7 October 2026. Retired versions do not degrade gracefully — calls simply stop succeeding.
A workable version discipline looks like this.
- Pin the version in one place. The version number should not be scattered across ten files and environment variables.
- Stay one version away from the edge. If the current release is v25, you should not be sitting on the oldest supported version.
- Treat upgrades as sprint work, not emergencies. Between releases, field names and enum values change far more often than the data model does.
- Read the changelog for the resources you actually use. Reading a whole release is pointless; two or three entities concern you.
- Validate on a test account before flipping production jobs.
New versions bring more than breaking changes. v25.2, for instance, added a flag indicating that a Target CPA or Target ROAS is too low for Search campaigns to enter auctions, plus percentile benchmark metrics. Upgrading is also how you get diagnostics that simply do not exist on an older version.
Migration checklist for an existing integration
- Inventory. List every place the API is called: ETL, dashboards, bidders, internal panels, one-off analyst scripts.
- Map the Cloud projects. For each integration, identify which project issued the OAuth credentials. This is where teams discover the project belongs to a former contractor’s personal account.
- Check each project’s access tier against the real operation volume.
- Transfer ownership to a corporate account if the project sits on a personal one. This is the single most expensive thing to discover during an offboarding.
- Check API versions everywhere from step 1. Anything on v22 must be rewritten before 7 October 2026.
- Audit refresh tokens and service accounts — which are in use, when they expire, who rotates them.
- Check login-customer-id on calls made under a manager account: it is the most frequent cause of permission errors.
- Run a smoke test on a test account before switching production jobs.
- Alert on authentication errors specifically, not only on whole-job failures.
- Keep an ownership page: project, owner, access tier, last activity date.
Common failures and how to read them
| Symptom | Likely cause | What to do |
|---|---|---|
| Authentication errors across all calls | Credentials issued from a project without the required access level | Reconcile the project that issued the credentials with the project that holds approved access |
| Permission denied on a specific account | Missing or wrong login-customer-id | Pass the manager account the request runs under |
| Calls stopped working all at once | API version retirement | Check the sunset date for the version in use |
| Access vanished after a quiet period | 90-day inactivity rule | Reapply and add a periodic keep-alive call |
| Basic application stuck | Project brand verification not completed | Clean up the consent screen, domain and company details |
| Fields missing from responses | Field renamed or removed in the new version | Check the changelog for that specific resource |
Quotas, volume and designing for load
An access tier constrains not so much how many rows you can read as the total volume of operations you are allowed. Three architectural consequences follow.
- Do not call the API for things a scheduled export already has. A daily report across a hundred accounts is far cheaper as one regular load into a warehouse than as a hundred live calls every time someone opens a dashboard.
- Cache reference data. Campaign structure and account lists change rarely; there is no reason to refetch them on every job run.
- Spread your peaks. If every job starts at midnight on the same schedule, you manufacture your own spike and hit errors in a setup where the daily budget of operations was never the problem.
Retries are their own cost centre. A job that dies mid-run without idempotency will spend the same volume again on restart. Process in batches with recorded progress so a rerun resumes from the break rather than from zero.
Do you even need the API?
Access costs effort, and for many teams the honest answer is “not yet.” A rough guide:
- Up to five accounts, standard reporting. The interface plus custom columns and the report editor is enough.
- You need overnight checks and reactions. That is the territory of automated rules and Google Ads scripts.
- You need analytics on raw data. Often cheaper than writing a connector: the Google Ads to BigQuery transfer.
- Dozens of accounts, custom bidding logic, CRM integration. Now the API earns its keep — and the boundary between it and in-account automation is mapped in Google Ads API vs scripts.
Separately: if what you need is not programmatic control but a fast answer about one account, 2026 added a third path — the agent inside the interface. What it can do and where it needs fences is covered in our piece on Ask Advisor in Google Ads.
If you are on v22 with days to go
Unpleasant but manageable. Work from cheapest action to most expensive.
- Identify what breaks first. Sort jobs into three buckets: money-critical (bidder, conversion uploads, budget management), decision-critical (daily reporting) and everything else. Migrate in that order.
- Start with writes, not reads. Reporting that stops is an inconvenience for a day. Offline conversion uploads that stop corrupt bid strategy learning, and the consequences stretch over weeks.
- Look at the actual delta. In most integrations the gap between adjacent versions is a handful of renamed fields and enum values — hours of work, not weeks. The panic usually costs more than the upgrade.
- Switch off the optional. If a report exists because it has always existed, pause it for the migration and free up hands.
- Move reporting to a transfer. Wherever you need data rather than control, a scheduled load into a warehouse removes API version dependency from your own scripts.
- Add alerts before, not after. A dedicated alert on authentication and version errors surfaces the problem at sunset, not a week later through odd-looking numbers.
Three expensive misconceptions
- “We have a token, so we have access.” The token no longer determines your access level — the project does. Verify the project that issued the credentials.
- “The old version will keep working for a while.” Version retirement is not graceful degradation; calls stop. There is no “we will fix it when it breaks” plan available here.
- “Access was granted once and is permanent.” The inactivity rule and mandatory brand verification make access a state you maintain, not an event you survived.
Security: who actually owns your access
Moving entitlement onto the Cloud project makes ownership critical. Three rules worth writing down.
- The project belongs to the company, not a person. A corporate account owns it; developers get roles, not ownership.
- Separate projects by purpose. Internal reporting and a client-facing product should not share a project: different review requirements, different blast radius if access is revoked.
- Rotation and logging. Credentials live in a secret manager, rotation is scheduled, access to secrets is role-based.
These are an extension of ordinary access hygiene inside the ad account itself — roles, corporate email, modern sign-in. More on that in Google Ads account access security. If you operate on agency Google Ads accounts, agree with your access provider in advance whether programmatic access to those accounts is permitted and under which manager account — a question best settled before the first line of code. The wider operations stack is listed on the PPC Rebels services page.
FAQ
Will my developer token stop working?
Existing tokens are still accepted in calls but are now optional: your access level is determined by the Cloud project, not by the token. New tokens have not been issued since 9 September 2026.
What if I am starting from scratch?
Sign up directly in the Google Cloud Console: create a project, configure the OAuth consent screen, apply for the access tier you need and complete brand verification.
Do I still need a Google Ads manager account to get access?
Not for a new sign-up — the process runs through the Cloud Console. A manager account remains useful for day-to-day operations across multiple advertising accounts.
How does Basic differ from Standard?
Basic covers a limited operation volume and goes through automated review. Standard targets high volumes, is reviewed manually, and expects a clear description of your product and use cases.
How long does approval take?
Basic typically returns quickly thanks to automated review; Standard takes longer because a person reads it. Build slack into your timeline and do not apply the week before a release.
What exactly does brand verification check?
That the project matches a real brand: domain ownership, OAuth consent screen, product name, privacy policy and terms of service. Inconsistencies between these items are the usual reason an application comes back.
What happens to v22 calls on 7 October 2026?
They stop succeeding. Migration has to be complete before that date or anything depending on the old version halts.
How often should I upgrade the API version?
Plan around roughly one version per year and never sit on the oldest supported release. Treat the upgrade as scheduled work, not incident response.
My project sat unused for six months — now what?
Most likely access was lost to the 90-day inactivity rule. You will need to regain access; add a periodic housekeeping call so it does not repeat.
Can one project serve several clients?
Technically yes, operationally it is better to split them: different clients mean different review expectations, different responsibility and a different cost if access is revoked.
Do I need the API with three accounts?
Usually not. At that scale custom columns, automated rules and scripts cover the work. The API earns its place when you add custom logic on top of the data or manage dozens of accounts.
Do service accounts follow the new model?
Yes. The principle is identical: the access level comes from the Cloud project that issued the credentials, whether the flow is user authentication or a service account.
