The "on the wire" panel is the useful part. It shows the raw HTTP your request produces, which is what you compare against a working example when something returns 401 and the error says nothing.
Where the credential goes
Header — correct. Authorization: Bearer … or a custom X-API-Key. Headers are not logged by default, do not appear in browser history, and are not sent in Referer.
Query parameter — flagged as a problem, because it is one. A key in a URL is recorded in web server logs, reverse proxy logs, CDN logs and browser history, and is sent in the Referer header to every third-party resource the destination page loads. You cannot enumerate everywhere it ended up.
Some APIs still require it. When they do, treat that key as lower-trust: restrict it by IP, scope it tightly, and rotate it more often.
Keep the key out of your shell history
A key typed on the command line is written to ~/.bash_history or ~/.zsh_history in plaintext, and is visible in ps output while the command runs.
# Wrong
curl -H "Authorization: Bearer sk_live_abc123" https://api.example.com/v1/me
# Right
export API_KEY="sk_live_abc123"
curl -H "Authorization: Bearer $API_KEY" https://api.example.com/v1/meBetter still, curl --netrc with a .netrc file that is mode 600 and gitignored, so the key never appears in a command at all.
Useful flags
-sS— quiet, but still show errors. The right default for scripts;-salone hides failures.-w '\nstatus: %{http_code}\n'— print the status code, since curl does not by default.-v— show the full request and response headers. This is what you want when debugging authentication.-i— include response headers in the output without the full verbose trace.--fail-with-body— non-zero exit on HTTP errors while still printing the body.
Why https matters even locally
An http:// URL is flagged because the credential crosses the network in the clear. On localhost the risk is small; the habit is what causes the problem, since the same command gets copied to a staging URL. Use https:// everywhere.
Frequently asked questions
Why does my curl request work but my application's does not?
Run curl with -v and compare the raw request against what your HTTP client sends. Common differences: a trailing newline in the header value, a client that lowercases headers, a proxy stripping Authorization on redirect, or a missing Content-Type.
How do I send a JSON body correctly?
-d '{"key":"value"}' with -H 'Content-Type: application/json'. Without the content type, many APIs treat the body as form-encoded and reject it. The generator adds it automatically when a body is present.
Can I use this with a self-signed certificate?
-k skips certificate verification, and you should use it only against a local development server you control. Disabling verification in anything else means the credential can be intercepted — the hardcoded secret linter flags the equivalent in application code as critical.
How do I test the failure cases?
Send a deliberately wrong key and confirm you get 401 rather than 403 or 500. The 401 and 403 simulator shows what each response should look like, and the authentication sandbox walks the whole decision path.