Skip to main content
Relay uses a small set of X-WR-* request headers to control routing and behavior, plus standard auth and request-id headers. Anything Relay doesn’t recognize is left alone.

​
Request headers

​
How Relay finds your relay key

In normal mode, Relay looks for the relay key in this order:
  1. X-WR-API-Key
  2. Authorization: Bearer <token>
  3. x-api-key
Use whichever fits your client. If you’re pointing an existing OpenAI or Anthropic SDK at Relay, just set its API key — it lands in Authorization or x-api-key and Relay picks it up.

​
Response headers

Relay forwards the upstream provider’s response headers through to you, minus hop-by-hop headers. On cross-shape translated responses, Content-Length and Content-Encoding are dropped, since the translated body differs from the upstream’s.

​
What Relay strips before calling upstream

Relay never leaks its own auth or control headers to the provider. Before forwarding a request upstream it removes:
  • Authorization and x-api-key (replaced with the correct upstream credential)
  • Cookie
  • every X-WR-* header
  • standard hop-by-hop headers
This is why your relay key is safe to send as a bearer token: it’s used to authenticate you to Relay, then stripped — it never reaches the provider.

​
Client IP and trusted proxies

For anonymous proxy rate limiting, Relay needs your real client IP. If Relay sits behind a load balancer, set RELAY_TRUSTED_PROXIES to a comma-separated list of CIDRs; Relay then trusts X-Forwarded-For from those peers and uses the rightmost untrusted IP. Unset, it uses the direct connection address.