How to use API key in cURL for authentication

Protected HTTP APIs often rely on API keys to identify trusted clients and throttle or block anonymous traffic. Using cURL with an API key enables scripts, scheduled jobs, and ad‑hoc debugging sessions to access those endpoints without interactive login or browser flows.

An API key is typically injected into the HTTP request as an Authorization header with a vendor-specific scheme, a dedicated x-api-key header, or a query parameter. cURL exposes these fields through the --header option and the URL query string, so the key travels with each request in exactly the shape expected by the API.

API keys behave like passwords and usually grant access to billing-sensitive or private data, so storage and transport require extra care. Secrets placed directly on the command line can leak into shell history, process listings, or shared logs; environment variables and configuration files reduce exposure but still require rotation and revocation policies. Keeping keys in headers rather than URLs also avoids accidental disclosure in web server logs and monitoring tools.

1. Send an HTTP GET request that passes the API key in the Authorization header using cURL.

   $ curl --header "Authorization: ApiKey YOUR_API_KEY" "https://api.example.com/data"
   {
     "data": "sample response"
   }

   Replace YOUR_API_KEY with the key issued by the service and keep the exact header scheme documented by the API provider.

2. Use a custom header name when the API expects a dedicated key header such as x-api-key.

   $ curl --header "x-api-key: YOUR_API_KEY" "https://api.example.com/data"
   {
     "data": "sample response"
   }

   Many providers expose API key authentication only via vendor-specific headers such as x-api-key or X-API-KEY instead of the Authorization header.

3. Pass the API key as a query parameter only when the API documentation explicitly requires it.

   $ curl "https://api.example.com/data?api_key=YOUR_API_KEY"
   {
     "data": "sample response"
   }

   Placing secrets in the URL exposes them to logs, proxies, and browser histories because many systems record full request URLs, including query strings.

4. Store the API key in an environment variable to avoid hard-coding it in repeated cURL commands.

   $ export API_KEY="YOUR_API_KEY"

   Environment variables keep secrets out of script files and allow reuse across multiple commands in the same shell session.

5. Send the API key from the environment variable through the Authorization header.

   $ curl --header "Authorization: ApiKey $API_KEY" "https://api.example.com/data"
   {
     "data": "sample response"
   }

   Quoting the header string protects special characters inside the key while expansion of $API_KEY injects the secret only at runtime.

6. Inspect headers and status codes using verbose output to confirm that the API key is present and accepted.

   $ curl --header "Authorization: ApiKey $API_KEY" "https://api.example.com/data" --verbose
   > GET /data HTTP/1.1
   > Host: api.example.com
   > Authorization: ApiKey YOUR_API_KEY
   ##### snipped #####
   < HTTP/1.1 200 OK
   {
     "data": "sample response"
   }
   
   $ curl --header "Authorization: ApiKey INVALID_KEY" "https://api.example.com/data" --verbose
   ##### snipped #####
   < HTTP/1.1 401 Unauthorized

   Success signals: verbose output shows the expected authentication header in the request and the server responds with a 2xx status for valid keys, while invalid keys produce 401 or 403 responses.

7. Unset the environment variable after use to limit exposure of the API key.

   $ unset API_KEY

   Leaving a key in the environment allows child processes or later shell commands to read it, which increases the chance of leaking the secret in logs or diagnostic output.