Security and configuration
Key handling, data flow, and scoping access.
Where should the key live?
Server side. Treat it like a password: never ship it in client-side code and never commit it
to a repository. An environment variable such as ROUTEMUX_API_KEY is the usual home.
A key in a browser bundle is a key anyone can read and spend.
What happens to my request data?
It is forwarded to the upstream provider you selected, and the response is forwarded back. The gateway records what it needs for billing and observability — model, token counts, status, latency — so you can audit spend per request.
How do I limit blast radius?
Use several narrow keys rather than one broad one:
- one key per application and environment, so a leak is scoped to that surface
- revoke and reissue the affected key without touching anything else
- per-key spend stays visible, so an anomaly shows up as a spend anomaly
What if a key leaks?
Revoke it in the console. Revocation takes effect for new requests immediately; there is no grace period to wait out. Then issue a replacement and update the one environment that used it — which is only a small job if you split keys in the first place.
Are several auth headers a problem?
Only when they disagree. The same key in Authorization and x-api-key is de-duplicated
(some clients send both by design). Two different values return 400 AMBIGUOUS_API_KEY,
which usually means a stale key is still sitting in a field you stopped using.
Do I need to allow-list anything?
No. The gateway is reachable over the public internet at api.routemux.com and requires
only a valid key.