Request Headers
The small name-value fields attached to a request that carry its token, body format, cache rules, and other instructions.
See it
What it is
Request headers are small name-value fields sent with an HTTP request before its body. They carry context about the request rather than the main data: Authorization proves who is calling, Content-Type describes the body, Accept asks for a response format, and If-None-Match enables conditional caching. Header names are case-insensitive. They are the -H flags in a curl command and the headers object you hand to fetch.
Reach for a standard header whenever HTTP already has a place for the information. A bearer token belongs in Authorization, not a query string, and a JSON body's media type belongs in Content-Type. Custom headers are useful for application concerns such as Idempotency-Key or a request ID, but every new convention becomes part of the API contract.
Headers are not a secret compartment. Proxies and application logs can record them, browsers restrict some of them, and cross-origin custom headers can trigger a CORS preflight. Never log Authorization or cookie values, cap header sizes, and document which headers are required, optional, or returned on errors.
Ask AI for it
Update this Fetch API client to send Authorization: Bearer <token>, Accept: application/json, and Content-Type: application/json on JSON requests. Add a unique Idempotency-Key on retryable POST requests, forward the server's Retry-After and ETag headers to the caller, and redact Authorization, Cookie, and Set-Cookie from every log. Do not set Content-Type manually when the body is a browser FormData object.