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: nativegenerativelanguage.googleapis.com

and OpenAI-compatible/v1beta/openai

Reference: Google docs, "Using Gemini API keys"[https://ai.google.dev/gemini-api/docs/api-key] 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 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.

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.

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.

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