feat: Enable user definable values for headers for connections configured by administrators

Before Submitting

• I searched open and closed issues and discussions for an existing request.
• I checked whether this already exists on the dev branch or latest source.
• I understand that maintainers want a well-written issue or discussion before any code pull request.
• This request is not a security vulnerability.

Problem

Open WebUI allows administrators to configure shared LLM connections, but authentication headers are currently effectively shared by all users.

Our LLM gateway requires two types of credentials:

Authorization: Bearer
X-Service-Token:

The X-Service-Token is a service credential that should be configured once by the administrator and used for all users.

However, the Authorization token must be different for every Open WebUI user.

Currently, there is no straightforward way to configure this combination on an administrator-managed connection:

One or more headers with values defined by the administrator for all users
One or more headers with values supplied individually by each user

This makes it unnecessarily difficult to use Open WebUI with gateways that require both a shared service credential and per-user authentication.

Desired Behavior

Allow administrator-configured connections to define multiple HTTP headers, where each header can independently be configured as either:

Administrator-defined: One value shared by all users
User-defined: Each user provides their own value

For example:

Admin configuration:

URL: https://llm-gateway.example/v1

X-Service-Token:
Authorization: Bearer {{USER_TOKEN}}

The administrator would configure X-Service-Token once.

Each user would then provide their own Authorization token in their Open WebUI account settings.

Ideally, this should support arbitrary headers, not only Authorization, because different gateways may require additional user-specific information such as usernames, organization IDs, tenant IDs, or other identity headers.

Why This Matters

This would allow Open WebUI to work cleanly with enterprise LLM gateways where:

The gateway endpoint is centrally managed
A service credential is shared across all Open WebUI users
Each user has their own authentication credential
Additional user-specific headers may be required

It would improve:

Per-user authentication
Usage tracking and billing
Rate limiting
Authorization
Auditing
Multi-organization / multi-tenant deployments

Most importantly, users would not need to configure their own gateway URL or create a separate connection. The administrator retains full control over the connection while users only provide their own credentials.

Examples or References

Our current gateway requires:

Authorization: Bearer
X-Service-Token:

The X-Service-Token must be identical for all users, while the Authorization token must be different for each user.

A useful UI could therefore look like:

Connection: Company LLM Gateway

Admin-defined headers:
X-Service-Token: ********

User-defined headers:
Authorization: Bearer ********
X-Organization: ********

The same mechanism could support any arbitrary HTTP header.

Alternatives or Workarounds

We considered using Open WebUI user variables and a custom Pipe to inject the user's token into requests.

However, this requires implementing and maintaining custom Open WebUI code and does not integrate naturally with the existing administrator-configured connection system.

Another workaround is to let every user configure a direct connection, but this defeats the purpose of centrally managing the gateway URL and available models and makes it possible for users to connect to arbitrary endpoints.

A native per-user header mechanism for administrator-managed connections would provide a much cleaner and more secure solution.

Edit:
A web proxy can also be used to inject the administrator-defined X-Service-Token. However, this does not solve the per-user credential problem. The user-specific Authorization tokens are managed by another organization, and I do not have access to those credentials at all. Therefore, the proxy has no way to inject or derive the required user-specific token.

The issue names no files or tests; start by tracing administrator-managed connection configuration and the user account settings entry points. Define how shared and user-provided arbitrary headers are represented and applied, then verify that administrators can configure shared values and users can supply their own credentials without changing the managed connection endpoint.