Use case: We’re integrating the Windsor.ai API into an agent platform (Anthropic’s Claude Tag) that connects to APIs through a managed credential-injection layer. That layer — and a growing number of enterprise connector frameworks — can only inject credentials via HTTP request headers. It has no mechanism to place a secret in the URL as a query parameter, which is how Windsor.ai authentication works today.
The problem: Because the Windsor.ai API expects the API key as a URL query parameter, we’re currently blocked from connecting at all through this platform. This isn’t a config issue we can work around on our side without building extra proxy infrastructure to translate the credential from a header into a query param — which introduces security and maintenance overhead we’d rather not own just to route around an auth-format limitation.
Desired outcome: Add support for passing the Windsor.ai API key via an HTTP request header — either a standard Authorization: Bearer <key> header or a documented custom header (e.g. X-API-Key) — as an alternative to the existing query-parameter method. Keeping query-param auth for backwards compatibility is fine; we just need header-based auth as a supported option.
Why it matters beyond us: Placing API keys in URLs is also a broader security concern — keys in query strings tend to leak into server logs, proxy logs, and browser history. Header-based auth is the standard expected by most modern connector platforms and is generally considered better security practice, so this would improve compatibility for any customer integrating Windsor.ai through an enterprise or agent framework, not just our specific case.