litellm - 💡(How to fix) Fix gemini/ provider with custom api_base requires api_key even when azure_ad_token is set [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#26702Fetched 2026-04-29 06:12:37
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Participants
Timeline (top)
labeled ×1

We have two models on gsk-prod with identical litellm_params:

FieldValue
modelgemini/gemini-3-flash-preview
api_basehttps://dev.api.gsk.com/co/ent/gcp/gemini3-flash/global
drop_paramstrue
azure_ad_tokenset (non-empty)
  • GSKPlatform_gemini-3.0-flash — created on an older version, works correctly
  • Kc3ajs8TEUyP7jsX27WQwg_gemini-3.0-flash — newly created with same params, fails with Missing gemini_api_key

The newly created model only works after adding api_key to litellm_params. The existing model has no api_key field and works without it.

Error Message

litellm.APIConnectionError: Missing gemini_api_key, please set `GEMINI_API_KEY`
  File ".../litellm/llms/vertex_ai/vertex_llm_base.py", line 360, in _check_custom_proxy
    raise ValueError("Missing gemini_api_key, please set `GEMINI_API_KEY`")

Stack: vertex_and_google_ai_studio_gemini.py:async_completionvertex_llm_base.py:_get_token_and_url_check_custom_proxy

Root Cause

We have two models on gsk-prod with identical litellm_params:

FieldValue
modelgemini/gemini-3-flash-preview
api_basehttps://dev.api.gsk.com/co/ent/gcp/gemini3-flash/global
drop_paramstrue
azure_ad_tokenset (non-empty)
  • GSKPlatform_gemini-3.0-flash — created on an older version, works correctly
  • Kc3ajs8TEUyP7jsX27WQwg_gemini-3.0-flash — newly created with same params, fails with Missing gemini_api_key

The newly created model only works after adding api_key to litellm_params. The existing model has no api_key field and works without it.

Code Example

litellm.APIConnectionError: Missing gemini_api_key, please set `GEMINI_API_KEY`
  File ".../litellm/llms/vertex_ai/vertex_llm_base.py", line 360, in _check_custom_proxy
    raise ValueError("Missing gemini_api_key, please set `GEMINI_API_KEY`")
RAW_BUFFERClick to expand / collapse

Describe the bug

When creating a model with model: gemini/gemini-3-flash-preview and a custom api_base, LiteLLM throws Missing gemini_api_key, please set GEMINI_API_KEY even when azure_ad_token is set in litellm_params. However, an existing model on the same proxy with identical config works fine.

Context

We have two models on gsk-prod with identical litellm_params:

FieldValue
modelgemini/gemini-3-flash-preview
api_basehttps://dev.api.gsk.com/co/ent/gcp/gemini3-flash/global
drop_paramstrue
azure_ad_tokenset (non-empty)
  • GSKPlatform_gemini-3.0-flash — created on an older version, works correctly
  • Kc3ajs8TEUyP7jsX27WQwg_gemini-3.0-flash — newly created with same params, fails with Missing gemini_api_key

The newly created model only works after adding api_key to litellm_params. The existing model has no api_key field and works without it.

Error

litellm.APIConnectionError: Missing gemini_api_key, please set `GEMINI_API_KEY`
  File ".../litellm/llms/vertex_ai/vertex_llm_base.py", line 360, in _check_custom_proxy
    raise ValueError("Missing gemini_api_key, please set `GEMINI_API_KEY`")

Stack: vertex_and_google_ai_studio_gemini.py:async_completionvertex_llm_base.py:_get_token_and_url_check_custom_proxy

Questions to investigate

  1. Why does azure_ad_token not satisfy auth resolution in _check_custom_proxy for gemini/ provider with a custom api_base?
  2. What is different about the older model that allows it to work without api_key? Is there a DB field not returned by /model/info that's being used?
  3. Should azure_ad_token be a valid auth mechanism for gemini/ provider with custom api_base, or is api_key the correct field?

Environment

  • LiteLLM version: v1.81.14
  • Provider: gemini/ with custom api_base (non-Google endpoint)
  • Proxy: multi-pod GKE deployment

extent analysis

TL;DR

  • Setting api_key in litellm_params may resolve the Missing gemini_api_key error for newly created models with a custom api_base.

Guidance

  • Investigate why azure_ad_token is not satisfying auth resolution in _check_custom_proxy for the gemini/ provider with a custom api_base.
  • Compare the configuration and database fields of the working older model (GSKPlatform_gemini-3.0-flash) with the newly created model to identify any differences.
  • Verify if api_key is the required field for authentication with the gemini/ provider and custom api_base, or if azure_ad_token should be a valid alternative.
  • Consider adding api_key to litellm_params for newly created models as a temporary workaround.

Notes

  • The issue may be related to changes in authentication mechanisms or requirements between the older and newer versions of the model or LiteLLM.
  • Further investigation is needed to determine the root cause and the correct authentication mechanism for the gemini/ provider with a custom api_base.

Recommendation

  • Apply workaround: Add api_key to litellm_params for newly created models, as this has been shown to resolve the error in the given scenario.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

litellm - 💡(How to fix) Fix gemini/ provider with custom api_base requires api_key even when azure_ad_token is set [1 participants]