AQ. key returns 401 ACCESS_TOKEN_TYPE_UNSUPPORTED on generateContent

Gemini API
1

Hi, my Google Cloud project (projects/770445770651, “Default Gemini Project”) only generates AQ.-prefixed Authentication Keys in AI Studio - no option for a classic AIzaSy key.

Every call to generateContent with this key fails with 401, both using the x-goog-api-key header and the ?key= query param on https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent:

{

“error”: {

"code": 401,
    "message": "Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential.",
    "status": "UNAUTHENTICATED",
    "details": [{
      "reason": "ACCESS_TOKEN_TYPE_UNSUPPORTED",
      "metadata": {
        "method": "google.ai.generativelanguage.v1beta.GenerativeService.GenerateContent",
        "service": "generativelanguage.googleapis.com"
      }
    }]
  }
}

I confirmed this with a plain curl request directly against the API (not through any SDK or proxy), so it's not a client/library issue on my end. The old feedback form for this migration is now closed and points here instead.

Could you please restore AIzaSy-style key generation for this project, or fix AQ-key auth for the REST endpoint? Happy to provide more details. Thanks!
2

Hello @Massimo1 ,

These issues are not due to AQ format keys and mostly has other underlying reasons. Please note that AI Studio will only generate AQ format keys going forward. Please share the repro CURL.

3

Here’s the repro curl (key redacted, starts with AQ.):slight_smile:

curl -X POST \

“https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent” \

-H “x-goog-api-key: AQ.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx” \

-H “Content-Type: application/json” \

-d '{

"contents": [{
      "parts": [{"text": "Hello"}]
    }]
  }'

Response:
{
  "error": {
    "code": 401,
    "message": "Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential.",
    "status": "UNAUTHENTICATED",
    "details": [{
      "reason": "ACCESS_TOKEN_TYPE_UNSUPPORTED",
      "metadata": {
        "method": "google.ai.generativelanguage.v1beta.GenerativeService.GenerateContent",
        "service": "generativelanguage.googleapis.com"
      }
    }]
  }
}

Same result with ?key=AQ.xxx as a query param instead of the header. This project only offers AQ.-prefixed keys in AI Studio — no way to generate a classic AIzaSy key.
4

Hello @Massimo1 ,
Can you try replacing the model with a newer one? Please replace $GEMINI_API_KEY with your actual API key

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.7-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [
      {
        "parts": [
          {"text": "Hello"}
        ]
      }
    ]
  }'
5

Hi Mahesh,

thanks for the suggestion, but switching the model doesn’t change anything here — this is a 401 authentication error (ACCESS_TOKEN_TYPE_UNSUPPORTED), not a model or request issue. The request never even gets to the model selection.

I just re-tested with gemini-2.5-flash and a second model — identical 401 in both cases, via both the x-goog-api-key header and the key query param.

This doesn’t look like an isolated case — there are several parallel threads in this forum reporting the exact same error on accounts that can only issue AQ. keys, for example this one: Account only issues AQ. keys — all return 401 ACCESS_TOKEN_TYPE_UNSUPPORTED

Same pattern everywhere: project correctly configured, API enabled, billing on — still a 401 on every AQ. key. This looks like a backend incompatibility between the new AQ. key format and the existing REST endpoints, not a config issue on my end.

Could you escalate this internally instead of treating it as a one-off ticket? And is there any way to temporarily get a classic AIzaSy key for this project until it’s fixed?

Thanks!

6

Which second model did you use? Can you please share the CURL?

7

Update: I retested with gemini-3.6-flash and it works — got a valid response back, no auth error at all.

So the root cause turns out to be model deprecation, not the AQ. key itself: gemini-2.5-flash and gemini-2.0-flash now return 404 “no longer available, use gemini-3.6-flash”, and gemini-1.5-flash returns 404 “not found”. Earlier, before those models were fully deprecated, the same calls returned the 401 ACCESS_TOKEN_TYPE_UNSUPPORTED error instead — which is why it looked like an auth/key-format problem rather than a model availability one.

@Mahesh_Sutar your suggestion to switch models was actually the right call, sorry for the pushback — the error message just made it look like an auth issue rather than a deprecated-model issue. Really appreciate you and @Aakash_Bansal sticking with this and asking the right follow-up questions to get to the bottom of it — thank you both, genuinely!

For anyone else hitting this: if you’re on an AQ. key and getting 401 ACCESS_TOKEN_TYPE_UNSUPPORTED (or 404 “no longer available”) on gemini-2.5-flash / gemini-2.0-flash / gemini-1.5-flash, switch to gemini-3.6-flash — that resolved it for me.

8

Thanks for confirming. we are working on providing a more meaningful error message for this!