I Got the Email about Google Ads API transitioning from developer tokens to Google Cloud projects., Here’s What It Actually Says

I was about to shut my laptop for the night when an email from the Google Ads Team slid into my inbox. Subject line: “Google Ads API transitioning from developer tokens to Google Cloud projects.” My first thought was the one I always have when Google emails me about the Ads API — great, what are they deprecating now. Second thought: do I actually have to do anything, or can I ignore this for six months like every other migration notice?

I run a handful of small sites and I’ve tinkered with the Google Ads API for reporting — pulling campaign numbers into a spreadsheet instead of clicking around the web console. Nothing fancy. I got a developer token ages ago, stuffed it into my code’s config, and promptly forgot about it. So this email was aimed squarely at people like me.

The short version, because the email buries it under three paragraphs of corporate-speak: developer tokens are going away. Access levels are moving from the old token system over to Google Cloud projects. If you’re like me, you got that token years back and never once thought about which Cloud project it was attached to — or whether it was attached to one at all.

The part that made me sit up: my access level had already been moved to a Cloud project automatically. I didn’t lift a finger. Google just migrated it for me. That’s… honestly kind of nice? Usually these migrations are a checklist of manual steps with a red countdown banner breathing down your neck. This one, the email says, keeps my existing code working with zero changes.

So what do you actually have to do? Reading between the lines, two things.

First, stop sending the developer token in your API headers. Right now it’s optional. But the email is blunt about the timeline: releases coming in the first half of 2027 won’t accept developer tokens at all. That’s a grace period, not a free pass. I went and opened my reporting script, and sure enough, the token was sitting there in the client config, right where I’d left it years ago. If you’ve got a token hardcoded in a repo — and I know I’m not the only one who’s done exactly that — go find it and delete it while it’s still just “optional.” Otherwise you’re the person scrambling in 2027 when an API call that’s worked for years suddenly starts bouncing.

Second, update your API contact email. This is the sneaky part nobody talks about. Those compliance and admin emails you get about your API access? They currently go to whatever addresses are listed in the legacy API Center. That page is being decommissioned, and after that, those emails only go to Google Cloud project owners and editors. If you’re the only person on the project and your contact address is one you barely check, you’ll miss the notices. I added my current email as an editor on the project. Two minutes, done.

I’ll be honest, I’m still not entirely sure what my “EXPLORER” access level means or whether it matters for the basic reporting I do. I think it’s the lowest tier in the new project-based world, and for pulling numbers it’s probably fine. If I ever needed full production access I’d have to request a higher level through the Cloud Console, and I have a feeling that’s where the real friction hides. But I don’t need it yet, so I’m not going down that hole today.

One thing I do appreciate about this email: it’s the rare deprecation notice that doesn’t immediately break you. My code still runs. I’ve got until sometime in 2027 to clean up the headers. And honestly, tying access to a Cloud project makes sense — better IAM control, one less token floating around in random repos (guilty as charged), fewer credentials to leak.

Anyway, that’s the whole email. Boring and administrative on the surface, with one small foot-gun hiding in the “action required” section. I updated my contact email and jotted down the header change on my to-do list. The token’s still in my config for now. I’ll get to it.