How to authenticate with an API key in wget

API keys are a common way to protect private HTTP downloads, report endpoints, and simple machine-to-machine integrations without building a full interactive login flow.

In wget, API-key authentication usually means sending the key in a request header with --header. Some providers use a custom field such as X-API-Key, while others expect the key inside Authorization with a vendor-specific scheme. The exact header name and value format must come from the API documentation.

The safest workflow keeps the key out of shell history as much as practical, validates the request against a low-risk echo endpoint first, and falls back to query parameters only when the provider explicitly requires them. The examples below use httpbin.org to prove what wget actually sends before switching to a real API URL.

Steps to authenticate with an API key in wget:

Load the key into the current shell from a prompt, secret manager, or restricted file before building requests.
```
$ read -rsp 'API key: ' API_KEY
$ printf '\n'
$ [ -n "$API_KEY" ] && echo 'API key loaded for this shell.'
API key loaded for this shell.
```
Interactive input keeps the secret out of visible command text, but the value still remains in the active shell until it is unset.
Send the key in a custom header when the API expects a field such as X-API-Key.
```
$ wget -qO- \
  --header="X-API-Key: ${API_KEY}" \
  https://httpbin.org/headers \
  | jq -r '.headers["X-Api-Key"]'
demo-key-123
```
If the echoed value matches, wget sent the header exactly as configured.
Use the provider's documented Authorization scheme when the key belongs there instead of in a custom field.
```
$ wget -qO- \
  --header="Authorization: ApiKey ${API_KEY}" \
  https://httpbin.org/headers \
  | jq -r '.headers.Authorization'
ApiKey demo-key-123
```
Common schemes include ApiKey, Token, and provider-specific prefixes, so copy the documented format exactly instead of guessing.
Append the key as a query parameter only when the API explicitly requires URL-based authentication.
```
$ wget -qO- \
  "https://httpbin.org/get?api_key=${API_KEY}" \
  | jq -r '.args.api_key'
demo-key-123
```
Query parameters are routinely logged by proxies, analytics, and monitoring systems, so they are usually the least private way to transport an API key.

Confirm the response code before building automation around the request.

$ wget --server-response \
  --header="X-API-Key: ${API_KEY}" \
  --output-document=/dev/null \
  https://httpbin.org/headers 2>&1 | sed -n '1,10p'
--2026-03-27 06:57:06--  https://httpbin.org/headers
Resolving httpbin.org (httpbin.org)... 44.221.213.41, 54.146.128.0, 44.196.185.120, ...
Connecting to httpbin.org (httpbin.org)|44.221.213.41|:443... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK

A clean 200 OK or the API's documented success code is a better automation gate than assuming a saved file means the request was authorized.

Unset the key when the session is complete.
```
$ unset API_KEY
$ echo "$API_KEY"
```
Unsetting removes the variable from the current shell only, so copied output files and shared logs still need separate cleanup.