Feature description
Custom enterprise gateways (e.g. Apigee-fronted proxies) require x-api-key: <token> rather than Authorization: Bearer <token>. Wave currently hardcodes the latter for all non-Azure providers, making such gateways unusable.
Implementation Suggestion
Add an optional ai:apikeyheader field in waveai.json mode config that, when set, overrides the header name used to send the API token. When the custom header is set, send \<header\>: <token> instead of Authorization: Bearer <token>. Azure providers (which use api-key) are unaffected.
Example config:
{
"my-gateway": {
"display:name": "My Gateway",
"ai:apitype": "openai-chat",
"ai:endpoint": "https://gateway.example.com/v1/chat/completions",
"ai:apitoken": "$ENV:MY_API_KEY",
"ai:apikeyheader": "x-api-key"
}
}Parallel problem in Warp terminal: warpdotdev/warp#11607
Feature description
Custom enterprise gateways (e.g. Apigee-fronted proxies) require
x-api-key: <token>rather thanAuthorization: Bearer <token>. Wave currently hardcodes the latter for all non-Azure providers, making such gateways unusable.Implementation Suggestion
Add an optional
ai:apikeyheaderfield inwaveai.jsonmode config that, when set, overrides the header name used to send the API token. When the custom header is set, send\<header\>: <token>instead ofAuthorization: Bearer <token>. Azure providers (which useapi-key) are unaffected.Example config:
{ "my-gateway": { "display:name": "My Gateway", "ai:apitype": "openai-chat", "ai:endpoint": "https://gateway.example.com/v1/chat/completions", "ai:apitoken": "$ENV:MY_API_KEY", "ai:apikeyheader": "x-api-key" } }Parallel problem in Warp terminal: warpdotdev/warp#11607