DEV Community

Cover image for I Created a Gemini API Key and Got AQ. Instead of AIza
Rapls
Rapls

Posted on

I Created a Gemini API Key and Got AQ. Instead of AIza

I created a free Gemini API key in Google AI Studio. When I went to copy it, I stopped. It started with AQ.Ab. Not the AIza I had been looking at for as long as I can remember.

My first thought was that something had gone wrong with my account. A leaked key, or a restriction, or some flag on the project. I looked into it, and it was none of that. Google is partway through changing how API keys are issued, and a freshly created key now comes out in the new format. Nothing broke. This is the plan.

That said, you can't drop the new key into every path and expect it to work. Some routes reject it. I run a WordPress plugin called Rapls AI Chatbot, and one of its no-card onboarding paths uses the Gemini free tier, so the first thing I did was check what was affected. Here is the short version before the details. The new AQ. key works fine on the native Gemini endpoint. It gets rejected on OpenAI-compatible endpoints and by some third-party tools that assume the AIza format.

Checked: June 2026
Issued from: Google AI Studio (free tier)
Routes tested: native generativelanguage.googleapis.com and OpenAI-compatible /v1beta/openai
Reference: Google docs, "Using Gemini API keys" https://ai.google.dev/gemini-api/docs/api-key

From AIza to AQ., what is actually happening

Google is moving Gemini API keys from the old Standard key (AIza...) to a new Auth key (AQ.Ab...). Keys you create in AI Studio now come out as Auth keys automatically. So someone who saw AIza yesterday gets AQ. today. That is what happened on my end.

There are dates attached, and this was the part that mattered most. Starting June 19, 2026, the Gemini API began rejecting requests from unrestricted Standard keys. By the time I am writing this, that deadline has already passed. Then in September 2026, Standard keys get rejected outright. Restricted or not, an AIza Standard key stops working after September.

One thing worth adding. A Standard key with an explicit restriction keeps working past June 19. So it is not that every AIza key died on the 19th. The unprotected ones go first, and the rest follow. It is a staged shutdown.

Auth keys behave a little differently in one place. Requests authenticated with an Auth key do not show up in Google Cloud's service account usage metrics. The project and key live on the AI Studio side. If you have been watching requests in the Cloud Console, your numbers may stop adding up, and that is why.

The trap I hit was compatibility, not the key itself

The format change matters less than the compatibility fallout. The AQ. key has a few known snags. Here is what I saw in my own testing alongside what people are reporting on the official forum.

Route How the key is passed What the AQ. key does
Native Gemini ?key= query or x-goog-api-key header Works. curl returns 200
OpenAI-compatible Authorization: Bearer to /v1beta/openai/... 400 with Multiple authentication credentials received. 401 in some implementations
AIza-assuming third party Tool expects the AIza format internally 401 invalid_api_key

Native is fine. If you hit generativelanguage.googleapis.com directly and pass the key as a query param or header, AQ. goes through the same as before. The official SDKs (google-genai and friends) handle that internally, so going through an SDK you probably will not even notice.

The OpenAI-compatible path is where it jams. Send an AQ. key with Authorization: Bearer to an OpenAI-compatible endpoint and it can come back with Multiple authentication credentials received, as if you passed credentials twice. In the same family of reports, a key that returns 200 through the native route still comes back as 401 invalid_api_key once a tool quietly routes it through an OpenAI-compatible transport. The nasty part of that second case is that the key is alive, but the error says the key is invalid. Trust the message, blame the key, and you never get out of the loop.

Some desktop tools that assume the AIza format throw the same 401.

In my case, the plugin talks to Gemini natively, so the AQ. key sailed through. To be safe I ran a new AQ. key through a full round trip, and it sent and received without trouble. I am folding that confirmation into the plugin's guidance in an update going out the next day. If I had been routing through an OpenAI-compatible path, users would have hit a 401 the moment they pasted a new key. With something you ship, your code being correct does not help. What piles up is a stack of "I entered the key and it will not work" reports. I was glad I checked first.

If you are still on an AIza key

This part I will spell out. If you are running on a key that starts with AIza and it still works, that is not a reason to relax. The dates above are why.

Check whether the key is restricted. In the AI Studio key list, if a key carries the Unrestricted label, that is the kind that stops after June 19. To keep it alive, restrict it. Hover the Unrestricted label on the API Keys page, click Add restrictions in the dialog, choose Restrict to Gemini API only, and confirm with Restrict key. Now it is locked to the Gemini API and keeps running past June 19.

This restriction only buys time. September pulls in Standard keys as a whole, so even a restricted AIza key eventually stops. Treat it as breathing room for an unhurried migration, nothing more. The destination is the AQ. Auth key.

Restricting a key needs the apikeys.keys.update permission on the relevant Google Cloud project, which the API Keys Admin and Editor roles already include. If your key is shared across other Google APIs (not a setup you want), you restrict it from the Cloud Console rather than AI Studio.

For what it is worth, the forum also has a separate thread about accounts getting restricted and no longer being able to create AIza keys at all. The AQ. issuance here is unrelated. It is the format change that applies to everyone. A new key coming out as AQ. does not mean something is wrong with your account.

One line of action

Put together, there is not much to verify on your end. If you are using a new AQ. key, confirm your traffic goes to the native Gemini endpoint. If you run an OpenAI-compatible path, test on real hardware whether Authorization: Bearer accepts the AQ. key. If you are still on an AIza key, restrict it to buy time and move to AQ. before September. That is the whole list.

Back to where I started. Staring at AQ.Ab in AI Studio with my hand frozen over the copy button, I suspected the key. What I actually had to fix was not the key. It was how I was handing the key to each route. If you froze at the same screen, point your suspicion at the route first.

Reference: Google AI for Developers, "Using Gemini API keys" https://ai.google.dev/gemini-api/docs/api-key

Top comments (4)

Collapse
 
merbayerp profile image
Mustafa ERBAY

I suspect weโ€™re going to see a lot of โ€œGemini API key is brokenโ€ posts over the next few months ๐Ÿ˜„. In most cases, the key will be fine and the actual culprit will be an OpenAI-compatible wrapper, SDK, or gateway making assumptions about the old AIza format.

Collapse
 
rapls profile image
Rapls

Agreed, and the tell will be that the same key works in a raw call and fails through the wrapper. That points the finger at the layer, not the credential. When I switched, the native Gemini endpoint took the AQ. key with no change, because it never cared about the prefix shape. The breakage shows up exactly where someone validated the key against an AIza pattern, or where an OpenAI-compatible shim assumed a format it was never promised.

That's the part worth saying out loud: a key format was never a contract. Anything regex-matching AIza to "verify" a key was encoding an assumption the provider didn't owe them, and the AQ. switch just collected the bill. The fix in most of those posts won't be a new key, it'll be deleting a validation that should never have been that specific. Good call flagging the wrapper layer, that's where the noise is going to come from.

Collapse
 
technogamerz profile image
๐•‹๐•™๐•– ๐•ƒ๐•’๐•ซ๐•ช ๐”พ๐•š๐•ฃ๐•

ๅŒใ˜ๅ•้กŒใซ้ญ้‡ใ—ใพใ—ใŸ๏ผ๐Ÿ˜…
็งใฏ AIza... ใงๅง‹ใพใ‚‹ใ‚ญใƒผใŒ็™บ่กŒใ•ใ‚Œใ‚‹ใจๆ€ใฃใฆใ„ใพใ—ใŸใŒใ€Google AI Studio ใงใฏไปฃใ‚ใ‚Šใซ AQ... ใฎใ‚ญใƒผใŒ็”Ÿๆˆใ•ใ‚Œใพใ—ใŸใ€‚

่ชฟในใฆใฟใŸใจใ“ใ‚ใ€Google ใฏๅพ“ๆฅใฎๆจ™ๆบ– API ใ‚ญใƒผใฎไปฃใ‚ใ‚Šใซใ€ๆ–ฐใ—ใ„ Auth Key ใ‚’ใƒ‡ใƒ•ใ‚ฉใƒซใƒˆใง็™บ่กŒใ™ใ‚‹ใ‚ˆใ†ใซใชใฃใŸใ‚ˆใ†ใงใ™ใ€‚ใ‚„ใ‚„ใ“ใ—ใ„ใฎใฏใ€ๅคšใใฎใƒ‰ใ‚ญใƒฅใƒกใƒณใƒˆใ‚„ใƒใƒฅใƒผใƒˆใƒชใ‚ขใƒซใ€SDK ใฎใ‚ตใƒณใƒ—ใƒซใŒไปŠใงใ‚‚ AIza ใ‚’ๅ‰ๆใจใ—ใฆใ„ใ‚‹ใŸใ‚ใ€ไฝ•ใ‹ๅ•้กŒใŒ่ตทใใฆใ„ใ‚‹ใฎใงใฏใชใ„ใ‹ใจๅ‹˜้•ใ„ใ—ใ‚„ใ™ใ„ใ“ใจใงใ™ใ€‚

ใ“ใฎ่จ˜ไบ‹ใ‚’ๆ›ธใ„ใฆใใ‚Œใฆใ‚ใ‚ŠใŒใจใ†ใ”ใ–ใ„ใพใ™๏ผใŠใ‹ใ’ใง็„ก้ง„ใชใƒ‡ใƒใƒƒใ‚ฐไฝœๆฅญใ‚’ใŸใใ•ใ‚“็œใใ“ใจใŒใงใใพใ—ใŸใ€‚

Collapse
 
manolito99 profile image
Lolo

Ran into something similar recently โ€” a rejection that read like a credentials issue but was actually a provider quietly deprecating something I'd hardcoded an assumption around. Same trap: the error message points one way, the real cause is somewhere else entirely.
Appreciate you logging the exact routes you tested. That table alone will save someone an afternoon.