BerriAI/litellm · error · BadRequestError

{exception_provider} - {message} This error occurs when lo

Error message

{exception_provider} - {message}

 This error occurs when load balancing Responses API across deployments with different API keys.
   Encrypted content is tied to the organization that created it and cannot be decrypted by other organizations.

   Solution: Enable 'encrypted_content_affinity' to route follow-up requests to the correct deployment:

   router_settings:
     enable_pre_call_checks: true
     optional_pre_call_checks:
       - encrypted_content_affinity

   Learn more: https://docs.litellm.ai/docs/response_api#encrypted-content-affinity-multi-region-load-balancing

What it means

Normalized BadRequestError with an appended how-to: the provider error contained 'invalid_encrypted_content' or 'could not be verified', which happens with the Responses API when encrypted reasoning/content items created by one organization (API key) are sent to a deployment under a different key — the ciphertext cannot be decrypted, so the provider rejects the request. LiteLLM's message explains enabling 'encrypted_content_affinity' routing so follow-ups return to the originating deployment.

Source

Thrown at litellm/litellm_core_utils/exception_mapping_utils.py:344

            message=f"ContentPolicyViolationError: {exception_provider} - {message}",
            llm_provider=custom_llm_provider,
            model=model,
            response=getattr(original_exception, "response", None),
            litellm_debug_info=extra_information,
        )
    elif "invalid_encrypted_content" in error_str or "could not be verified" in error_str:
        helpful_message: Final = (
            f"{exception_provider} - {message}\n\n"
            " This error occurs when load balancing Responses API across deployments with different API keys.\n"
            "   Encrypted content is tied to the organization that created it and cannot be decrypted by other organizations.\n\n"
            "   Solution: Enable 'encrypted_content_affinity' to route follow-up requests to the correct deployment:\n\n"
            "   router_settings:\n"
            "     enable_pre_call_checks: true\n"
            "     optional_pre_call_checks:\n"
            "       - encrypted_content_affinity\n\n"
            "   Learn more: https://docs.litellm.ai/docs/response_api#encrypted-content-affinity-multi-region-load-balancing"
        )
        raise BadRequestError(
            message=helpful_message,
            llm_provider=custom_llm_provider,
            model=model,
            response=getattr(original_exception, "response", None),
            litellm_debug_info=extra_information,
            body=getattr(original_exception, "body", None),
        )
    elif "invalid_request_error" in error_str and "Incorrect API key provided" not in error_str:
        raise BadRequestError(
            message=f"{exception_provider} - {message}",
            llm_provider=custom_llm_provider,
            model=model,
            response=getattr(original_exception, "response", None),
            litellm_debug_info=extra_information,
            body=getattr(original_exception, "body", None),
        )
    elif (
        "Web server is returning an unknown error" in error_str

View on GitHub (pinned to 6c2dcb801b)

Solutions

1. Enable affinity as the message instructs — in router settings: enable_pre_call_checks: true and optional_pre_call_checks: [encrypted_content_affinity] — so follow-ups stick to the deployment that created the encrypted content.
2. Alternatively route all Responses-API traffic for a given session/model to a single deployment/key (pin the deployment or remove cross-org mixing).
3. As a workaround, strip encrypted/reasoning items from follow-up payloads when cross-deployment replay is intended, at the cost of losing that state.

Example fix

# before (config.yaml)
router_settings:
  routing_strategy: simple_shuffle   # follow-ups may hit other org's key
# -> BadRequestError: invalid_encrypted_content ...

# after
router_settings:
  enable_pre_call_checks: true
  optional_pre_call_checks:
    - encrypted_content_affinity

null

def is_encrypted_content_error(exc: BaseException) -> bool:
    text = str(exc)
    return "invalid_encrypted_content" in text or "could not be verified" in text

from litellm import BadRequestError

try:
    resp = router.responses(model=m, input=inp)
except BadRequestError as e:
    if "encrypted_content_affinity" in str(e) or "invalid_encrypted_content" in str(e):
        resp = router.responses(model=m, input=strip_encrypted_items(inp))  # degrade gracefully
    else:
        raise

When it happens

Trigger: Load-balancing OpenAI Responses API calls across deployments with different API keys/orgs: call 1 (with encrypted reasoning items) lands on deployment A, call 2 referencing those items is routed to deployment B, provider returns invalid_encrypted_content, and this mapped error is raised.

Common situations: Router configs with multiple OpenAI keys/orgs for the Responses API; adding capacity mid-session; weighted routing ignoring conversation affinity; mixing proxy-managed keys from different orgs behind one model name.

Related errors

• invalid_encrypted_content
• LLM Router not initialized. Ensure models added to proxy.
• LiteLLM Managed File object with id={file_id} has no file_ob
• Unexpected responses stream payload
• Stream ended without a completed response

AI-assisted analysis of BerriAI/litellm@6c2dcb801b (2026-08-15). Data as JSON: /api/errors/94f0c3502eeca258. Report an issue: GitHub.