Error messages

API key not valid. Please pass a valid API key.

API key not valid. Please pass a valid API key.

Google's Gemini API sends this back as HTTP 400 when it can't make sense of the key on a request. The full response, as a September 2026 report logged it:

{
  "error": {
    "code": 400,
    "message": "API key not valid. Please pass a valid API key.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "API_KEY_INVALID",
        "domain": "googleapis.com",
        "metadata": { "service": "generativelanguage.googleapis.com" }
      }
    ]
  }
}

The Python SDK (google-genai, we read 2.25.0) puts 400 INVALID_ARGUMENT. in front of that and raises a ClientError. Gemini CLI wraps it in [API Error: ...]. As of September 25, 2026, 588 GitHub issues quote the message.

INVALID_ARGUMENT, but it's about the key

The status is the generic "bad request" one, which throws people. The reason field is what tells you it's the key: API_KEY_INVALID. The service line names generativelanguage.googleapis.com, the Gemini API endpoint Google AI Studio keys are meant for.

The key that got sent isn't the one you checked

This is the commonest story in the reports we read. The SDK looks in two environment variables, and the API key docs spell out the order: "If both are set, GOOGLE_API_KEY takes precedence." In 2.25.0 the SDK logs a warning when both are set, but a warning is easy to miss. An old GOOGLE_API_KEY in your shell profile beats the fresh GEMINI_API_KEY you just pasted.

Other versions of the same thing turn up too. One Gemini CLI user traced it to the CLI reading a project's .env file instead of the one in ~/.gemini. A web app running as a Cloudflare Worker hit it because the key secret had never been added there.

A key made for a different Google service

Google has more than one AI API, and their keys aren't interchangeable. When a Gemini CLI user got this with a key they swore was valid, a contributor pointed out it was a Vertex AI key (Vertex is Google Cloud's AI platform), while the CLI's API-key mode talks to the AI Studio endpoint, which rejects Vertex keys as invalid. The OmniRoute report above was the same mix-up in reverse: its code sent a Vertex Express key to the Gemini endpoint.

Keys are changing in September 2026

Google is moving the Gemini API from "standard" keys to "auth keys," which are tied to a service account. Every key created in AI Studio since May 28, 2026 is an auth key. The docs say unrestricted standard keys are already refused, and that "On September 2026" the API will reject standard keys altogether. They don't say which error that rejection comes with, so we can't tell you it's this one. If you have an older key, the AI Studio API keys page shows each key's type.

A leaked key is its own case, with its own words. Google's troubleshooting page says blocked leaked keys get "Your API key was reported as leaked. Please use another API key."

What to do

Print the first few characters of the key your process really sends and compare it with the list in AI Studio. Unset whichever of the two variables you don't mean to use. If the key is old, standard or came from Google Cloud for Vertex, create a new one in AI Studio. Don't retry. Google's troubleshooting page says not to retry a 400, and 400 isn't on the SDK's list of retryable codes either.