API keys act as lightweight credentials for calling protected HTTP endpoints, and combining them with wget enables unattended jobs to download reports, synchronize data, or trigger remote tasks on a regular schedule.
Most web services expect the key as part of the request, either in a dedicated header or as a query parameter. wget provides the --header option for injecting arbitrary headers and accepts URLs that already contain query strings, which covers most header-based and parameter-based key formats advertised by API documentation.
Because API keys frequently grant broad or irreversible access, their handling requires caution. Command history, process listings, and server logs can expose secrets when keys appear directly in command lines or URLs. The examples assume a Linux shell environment with wget installed and focus on patterns that keep keys reusable yet constrained to the current session.
Steps to authenticate using API key in wget:
- Open a terminal in a working directory that will store downloaded API responses.
$ cd ~/Downloads/api-reports $ pwd /home/example/Downloads/api-reports
Using a dedicated directory keeps downloaded files separated from other data and simplifies housekeeping.
- Define an environment variable to hold the API key for the current shell session.
$ export API_KEY='REPLACE_WITH_REAL_KEY' $ echo "$API_KEY" REPLACE_WITH_REAL_KEY
Environment variables keep the key out of repeated commands but can still be read by processes that inherit the shell environment.
- Send the key in a standard Authorization header using the --header option.
$ wget --header="Authorization: Bearer $API_KEY" https://api.example.net/v1/report --2025-02-01 09:00:00-- https://api.example.net/v1/report Resolving api.example.net (api.example.net)... 203.0.113.10 Connecting to api.example.net (api.example.net)|203.0.113.10|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 2048 (2.0K) [application/json] Saving to: ‘report.json’ report.json 100%[==================>] 2.00K --.-KB/s in 0s 2025-02-01 09:00:01 (25.4 MB/s) - ‘report.json’ saved [2048/2048]
Some services expect different schemes such as ApiKey or Token, so the header name and value format must match API documentation.
- Send the key in a custom header such as X-API-Key when the service defines its own header name.
$ wget --header="X-API-Key: $API_KEY" https://api.example.net/v1/report
Multiple --header options can be added to include both authentication and other required HTTP headers.
- Use a query-parameter key format only when an API explicitly requires a key in the URL.
$ wget "https://api.example.net/v1/report?api_key=$API_KEY" --2025-02-01 09:02:00-- https://api.example.net/v1/report?api_key=REPLACE_WITH_REAL_KEY Resolving api.example.net (api.example.net)... 203.0.113.10 Connecting to api.example.net (api.example.net)|203.0.113.10|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 2048 (2.0K) [application/json] Saving to: ‘report.json’
Full URLs frequently appear in reverse-proxy logs and access analytics, so keys placed in query parameters may be recorded and forwarded to third-party systems.
- Inspect response headers using --server-response to confirm that the request authenticated successfully.
$ wget --header="Authorization: Bearer $API_KEY" --server-response https://api.example.net/v1/report -O report.json --2025-02-01 09:03:00-- https://api.example.net/v1/report ##### snipped ##### HTTP/1.1 200 OK Content-Type: application/json Content-Length: 2048 ##### snipped ##### Saving to: ‘report.json’
Status codes like 200 and 204 indicate success, while 401 or 403 usually signal invalid credentials or insufficient permissions.
- Remove the API key environment variable after finishing authenticated downloads to limit exposure in descendant processes.
$ unset API_KEY $ echo "$API_KEY"
Clearing the variable reduces accidental reuse in later shells or scripts but does not erase keys already persisted in configuration files or secrets stores.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
Comment anonymously. Login not required.
