OpenAI-compatible provider: no way to add custom auth headers for enterprise API gateways

[ankitg12]

Problem

Several enterprise LLM gateways sit behind Azure API Management (APIM) or similar reverse-proxy layers that require a custom auth header instead of (or in addition to) the standard Authorization: Bearer <key> scheme — e.g. Azure APIM's well-known Ocp-Apim-Subscription-Key header. In these setups the actual OpenAI-style api_key field is often just a placeholder/dummy value, and the real credential must be sent via a separate header.

Today, OPENWIKI_PROVIDER=openai-compatible only accepts OPENAI_COMPATIBLE_API_KEY + OPENAI_COMPATIBLE_BASE_URL, which get passed straight into LangChain's ChatOpenAI({ apiKey, configuration: { baseURL } }) with no way to inject additional headers. This makes it impossible to point OpenWiki at any gateway that authenticates via a custom header rather than a bearer token — even though the endpoint itself is otherwise fully OpenAI-API-compatible.

Proposed solution

Add an optional env var, e.g. OPENAI_COMPATIBLE_EXTRA_HEADERS (JSON object, or repeated Header-Name=value pairs), that gets merged into configuration.defaultHeaders when constructing the ChatOpenAI client for the openai-compatible provider. This is a small, additive change — LangChain's ChatOpenAI/underlying openai SDK already supports defaultHeaders in its client configuration, so this would just be plumbing an existing capability through OpenWiki's provider config.

Example use case

export OPENAI_COMPATIBLE_BASE_URL="https://my-internal-gateway.example.com/openai"
export OPENAI_COMPATIBLE_API_KEY="placeholder"   # gateway ignores this
export OPENAI_COMPATIBLE_EXTRA_HEADERS='{"My-Gateway-Subscription-Key": "<real-key>"}'
openwiki personal

Happy to open a PR for this if the maintainers are open to the approach — wanted to check direction first since it touches the provider-construction code path in src/agent/index.ts.

[ankitg12]

For context: #187 is tackling a related but distinct gap — it adds an OPENAI_COMPATIBLE_AUTH mode (api-key | entra-id) for the same provider. That's great for Entra ID, but it's still a named-mode-per-mechanism approach. A generic OPENAI_COMPATIBLE_EXTRA_HEADERS escape hatch (as proposed above) would complement it by covering the broader class of gateways that authenticate via an arbitrary static header (e.g. Azure APIM's Ocp-Apim-Subscription-Key, or any other reverse-proxy convention) without needing a new named mode added for each one. Happy to scope this narrowly so it doesn't conflict with #187's changes to src/agent/index.ts.

[flowbar-api]

This is a real pain point. Azure APIM and similar gateways layer their own auth on top of the standard Bearer scheme, and most OpenAI-compatible clients don't let you inject extra headers without subclassing.

Two practical workarounds while waiting for first-class support:

1. Reverse proxy — put nginx/Envoy in front that merges the APIM header into requests before forwarding. Quick but adds operational overhead.
2. Use a gateway that speaks vanilla Bearer — if you can route through an OpenAI-compatible aggregator instead of going directly through APIM, you skip the custom header problem entirely. FlowBar (flowbarai.com) is one option that exposes a standard Bearer endpoint for 50+ models, so your existing client code just works.

Would be great to see an extra_headers or auth_scheme option in the provider config though — that's the proper fix.