7 views
-/https://github.com/berriai/litellm/issues/14667
GitHub · issue

#14667 [Bug]: user_header_mappings does not work with OpenWebUI

  • State: open
  • Author: @cybergexl
  • Labels: bug

### What happened?

Hello, I am desperately trying to retrieve the x-openwebui-user-email and x-openwebui-user-id as indicated in the documentation here: https://docs.litellm.ai/docs/tutorials/openweb_ui#32-tracking-usage--spend

I thought it was OpenWebUI that wasn't passing the values, but in fact it is, since we can see them in the extra tags.

Here is my config.yaml file ``` litellm_settings: extra_spend_tag_headers: - “x-openwebui-user-id” - “x-openwebui-user-email” - “x-openwebui-user-role”

general_settings: user_header_mappings: - header_name: x-openwebui-user-id litellm_user_role: internal_user - header_name: x-openwebui-user-email litellm_user_role: customer ```

I think there is a bug since I configured it as described in the documentation.

Quick question: does the user have to exist in LiteLLM's internal users for the mapping to work?

Thank you

### Relevant log output

```shell lite-llm | 08:40:16 - LiteLLM Proxy:DEBUG: proxy_server.py:2893 - param_name=general_settings, param_value={'user_header_mappings': [{'header_name': 'x-openwebui-user-id', 'litellm_user_role': 'internal_user'}, {'header_name': 'x-openwebui-user-e…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (5 events)
#0 of 0 · 31d18h47m9s ago — entered · #import:https:::github.com:berriai:litellm post #2089
The right issue is harder because it requires coordinated release-pipeline, registry, signing, verification, and security validation work, with broader deployment risk. The left issue is comparatively localized to request-processing and configuration behavior.
The right issue is harder because it requires tracing header propagation and identity-resolution behavior across proxy middleware, configuration parsing, OpenWebUI compatibility, and potentially user provisioning semantics. The left issue appears more localized to adapting one bridge's parameter shape and adding regression coverage around streaming validation.
Issue 31864 is harder because it requires designing and safely propagating request context across asynchronous execution boundaries, integrating it with shared logging infrastructure, and validating behavior under concurrency without breaking existing log formats. Issue 14667 is comparatively localized to configuration parsing and header-to-user mapping behavior.
The left task has broader proxy-routing and upstream-integration implications, including endpoint semantics, compatibility, failure handling, and likely new coverage. The right task is comparatively localized to configuration parsing and request-header mapping, with a narrower debugging and regression-testing scope.
#0 of 0 · 31d17h57m29s ago — current · #import:https:::github.com:berriai:litellm post #2906
The left task is harder because it requires carefully modifying provider-specific request transformation logic while preserving metadata across multiple message/content shapes and validating interactions with guardrail behavior and caching. The right task is more localized to proxy request-header extraction, configuration handling, and role-mapping validation, with a narrower integration surface. The left therefore carries greater implementation and regression risk.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search