What causes "Invalid proxy server token passed" in BerriAI/litellm?

Treat like any invalid-credential 401/500: verify the key exists via admin `/key/info` on the same proxy+DB

BerriAI/litellm · error · Exception

Invalid proxy server token passed

Error message

Invalid proxy server token passed

What it means

Legacy terminal guard in the litellm-ui token section: after budget checks, if `valid_token` is still None the proxy rejects the credential as an unknown proxy token (generic Exception, so surfaced as a 500-style error unless wrapped). In practice it means the key resolved to no token record — unknown, deleted, or from another environment.

Source

Thrown at litellm/proxy/auth/user_api_key_auth.py:2092

            valid_token_dict = valid_token.model_dump(exclude_none=True)
            valid_token_dict.pop("token", None)
            # budget_throttle_pct is excluded from model_dump (it must not leak
            # into serialized responses), so carry the request-scoped decision
            # forward by hand to the auth object the rate limiter receives.
            if valid_token.budget_throttle_pct is not None:
                valid_token_dict["budget_throttle_pct"] = valid_token.budget_throttle_pct

            if _end_user_object is not None:
                valid_token_dict.update(end_user_params)
                valid_token_dict["end_user_object_permission"] = _end_user_object.object_permission

        # check if token is from litellm-ui, litellm ui makes keys to allow users to login with sso. These keys can only be used for LiteLLM UI functions
        # sso/login, ui/login, /key functions and /user functions
        # this will never be allowed to call /chat/completions

        if valid_token is None:
            # No token was found when looking up in the DB
            raise Exception("Invalid proxy server token passed")
        if valid_token_dict is not None:
            virtual_key_auth_obj: Final = await _return_user_api_key_auth_obj(
                user_obj=user_obj,
                api_key=api_key,
                parent_otel_span=parent_otel_span,
                valid_token_dict=valid_token_dict,
                route=route,
                start_time=start_time,
            )
            virtual_key_auth_obj.via_virtual_key = True
            return virtual_key_auth_obj
    except Exception as e:
        return await UserAPIKeyAuthExceptionHandler._handle_authentication_error(
            e=e,
            request=request,
            request_data=request_data,
            route=route,
            parent_otel_span=parent_otel_span,

View on GitHub (pinned to 77b7c6c40c)

Solutions

Treat like any invalid-credential 401/500: verify the key exists via admin `/key/info` on the same proxy+DB
Re-authenticate (new `/key/generate` or fresh SSO/UI login) and use the newly issued key
Upgrade the proxy — newer code paths return the cleaner 401 'Invalid API key' for this condition

Example fix

# before
resp = client.chat.completions.create(...)  # Exception: Invalid proxy server token passed

# after
key = admin.post("/key/generate", json={"key_alias": "app"}).json()["key"]
client = OpenAI(base_url=..., api_key=key)

Defensive patterns

Strategy: try-catch

Validate before calling

r = httpx.get(f"{PROXY}/v1/models", headers={"Authorization": f"Bearer {key}"})
if r.status_code in (401, 500) and not r.is_success:
    raise RuntimeError("proxy did not recognize this token — obtain a fresh key")

Try / catch

try:
    resp = client.chat.completions.create(...)
except Exception as e:
    if "Invalid proxy server token passed" in str(e):
        client.api_key = reauthenticate()  # fresh /key/generate or SSO login
        resp = client.chat.completions.create(...)
    else:
        raise

Prevention

Re-authenticate on unknown-token errors instead of retrying the same credential
Keep the proxy current — newer builds map this to a clean 401
Use proxy-issued keys rather than tokens minted elsewhere

When it happens

Trigger: Presenting a key that no lookup (cache or DB) resolved, in the flow that reaches the UI-key comment block — e.g. a UI/SSO login key used where it is not recognized, or any token-shaped credential that slipped past the earlier 401 checks.

Common situations: SSO/UI session keys replayed against the wrong proxy or after DB resets; older LiteLLM versions where this is the primary 'key not found' error; clients ignoring earlier 401s and retrying.

Related errors

AI-assisted analysis of BerriAI/litellm@77b7c6c40c (2026-08-18). Data as JSON: /api/errors/2da7f9413d3056aa. Report an issue: GitHub.