What Is an API Key: How Keys Authenticate

An API key is an opaque secret the server already knows

An API key is a long, random string a provider issues to a caller. Each request presents that string; the server looks it up and maps it to an account. There is no signature to check and no claims to decode. If the key is in the store and not revoked, the request is authenticated.

GET /v1/forecast HTTP/1.1
Host: api.weather.example
X-API-Key: sk_live_4c9a1f7b2e8d...

That is the whole scheme. The key’s only protection is secrecy plus TLS. There is no exp built into the format. A leaked key works until someone deletes it.

This post is the mechanism. Whether keys are a good default is argued in In defence of API keys. How to generate, scope, and rotate them is in API key authentication best practices. When to prefer a JWT instead is in JWT vs API key auth for M2M.

Header versus query

Most providers want the key in a header (X-API-Key, X-Key, api-key). Some still accept a query parameter (?api_key=). Headers are the better default: query strings are copied into access logs, browser history, and Referer values.

A gateway that can place the same secret in either location is matching the vendor, not inventing a new scheme. In RequestRocket, credentialAuthType: "key" requires three secret fields: key (the header or query name), value (the secret), and addToHeader (true for a header, false for a query parameter). Optional prefix covers vendors that want Token in front of the value.

{
  "credentialType": "target",
  "credentialAuthType": "key",
  "credentialName": "weather-api-key",
  "credentialRegion": "us-east-1",
  "credentialSecret": {
    "key": "X-API-Key",
    "value": "sk_live_4c9a1f7b2e8d",
    "addToHeader": true
  }
}

Proxy credentials use the same type, with a hard constraint: inbound authentication to the gateway only accepts the Authorization header. A proxy key credential with key: "X-API-Key" will not work. Set key: "Authorization" (and a prefix if you want Bearer or Api-Key ). Target credentials have no such restriction – that is the point of putting the vendor’s odd header name on the outbound credential.

Lookup is not cryptography

Verifying an API key is a database (or hash) lookup. Verifying a JWT is a signature check against a public key, plus claim tests. The latency and failure modes differ:

API key:  extract value -> look up record -> allow or deny
JWT:      parse segments -> check alg/kid -> verify signature -> check exp/iss/aud

Keys win on simplicity and immediate revocation (delete the row). JWTs win on expiry and carrying identity without a round-trip. Using both – a gateway key for the caller, a vendor key or minted JWT toward upstream – is the split in API keys and JWTs, stronger together.

What an API key is not

It is not Basic Auth (that is a username and password, encoded, every time – What is Basic Auth). It is not a bearer token in the RFC 6750 sense, though many keys are sent as Authorization: Bearer <key>. It is not a JWT; if it has two dots and a signature, see What is a JWT.

Next steps

Put the vendor key in a target credential and give callers a separate proxy key. Configure both in the credentials guide. RequestRocket is runtime access control for AI agents and apps calling APIs you don’t own – every call gets a least-privilege credential, a policy check, and an audit record, with no code changes.