BerriAI/litellm · error · ValueError

Container API not supported for provider: {custom_llm_provid

Error message

Container API not supported for provider: {custom_llm_provider}

What it means

ValueError from _get_container_provider_config in litellm/proxy/container_endpoints/handler_factory.py when the Container API route is invoked with a custom_llm_provider other than 'openai', 'azure', or 'azure_text'. The container handler factory only has transformation configs for OpenAI and Azure; any other provider string reaches the unconditional raise. This surfaces to the caller as a 500-backed error from the /v1/containers routes.

Source

Thrown at litellm/proxy/container_endpoints/handler_factory.py:51


def get_all_route_types() -> list[str]:
    """Get all async route types for registration in route_llm_request.py"""
    config: Final = _load_endpoints_config()
    return [endpoint["async_name"] for endpoint in config["endpoints"]]


def _get_container_provider_config(custom_llm_provider: str):
    """Get the container provider config for the given provider."""
    if custom_llm_provider == "openai":
        from litellm.llms.openai.containers.transformation import OpenAIContainerConfig

        return OpenAIContainerConfig()
    elif custom_llm_provider in ("azure", "azure_text"):
        from litellm.llms.azure.containers.transformation import AzureContainerConfig

        return AzureContainerConfig()
    raise ValueError(f"Container API not supported for provider: {custom_llm_provider}")


def _create_handler_for_path_params(
    path_params: list[str],
    route_type: str,
    returns_binary: bool = False,
    is_multipart: bool = False,
):
    """
    Dynamically create a handler with the correct path parameter signature.
    """
    # For binary content endpoints, use a different handler
    if returns_binary and path_params == ["container_id", "file_id"]:

        async def handler_binary_content(
            request: Request,
            container_id: str,
            file_id: str,

View on GitHub (pinned to 77b7c6c40c)

Solutions

  1. Use provider 'openai' or 'azure'/'azure_text' for container operations — these are the only implemented Container configs.
  2. Remove the x-litellm-provider header so the default 'openai' is used against an OpenAI deployment.
  3. For other providers, call their native API directly instead of the /v1/containers proxy routes.

Example fix

# before
curl -X POST $PROXY/v1/containers -H 'x-litellm-provider: bedrock'

# after
curl -X POST $PROXY/v1/containers -H 'x-litellm-provider: azure'
Defensive patterns

Strategy: validation

Validate before calling

SUPPORTED_CONTAINER_PROVIDERS = {"openai", "azure", "azure_text"}

provider = request.headers.get("x-litellm-provider", "openai")
if provider not in SUPPORTED_CONTAINER_PROVIDERS:
    raise UnsupportedProvider(f"containers not available for {provider}; use openai or azure")

Type guard

def supports_container_api(provider: object) -> bool:
    return isinstance(provider, str) and provider in {"openai", "azure", "azure_text"}

Try / catch

try:
    resp = await proxy_client.post("/v1/containers", ...)
except ValueError as e:
    if "Container API not supported" in str(e):
        fall_back_to_native_provider_api(provider)
    else:
        raise

Prevention

When it happens

Trigger: POST /v1/containers (or files/collections sub-routes) with header x-litellm-provider: bedforge/anthropic/vertex_ai/gemini; a model deployment whose metadata routes containers to an unsupported provider; passing provider= in the query string for a provider with no Container implementation.

Common situations: Assuming the OpenAI-compatible Containers API works across all LiteLLM providers; wiring a generic passthrough client that always sends a provider header; upgrading LiteLLM and trying containers on a provider that was never implemented.

Related errors


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