When code finally calls an API, the secret has to ride along somewhere. Industry convention strongly favors HTTP headers over query strings, and often Authorization: Bearer <token-or-key> — even when the payload is technically an API key, not a JWT.
Headers are less likely to land in server access logs and browser history than ?key=… in the URL. If docs show a query param, check for a header variant — and avoid logging full requests in your own proxy middleware.
If the key lives only on a server you control, browsers never see it: your frontend talks to your API, and the server adds the provider secret. Coffee’s browser vault pattern exists because many Coffee demos run client-side — accept that as a deliberate trade (convenience vs exposure) and pair it with provider-side restrictions where available.
Coffee Server Keyman issues ck_… API keys for your machine’s HTTP boundary — same header culture, different trust domain than OpenAI’s dashboard keys stored in KEY1.