Technical
API key
API key is a secret string a program sends with each request so the service knows which account is calling. It names the caller; it does not prove which person is behind it.
How it is measured
Keys travel in a header (`Authorization: Bearer sk_live_...` or `X-API-Key`) or, worse, in a query string. The service looks the key up, checks its scope and rate limit, and logs the key id beside the request.
Watch use from the provider dashboard: last-used time, requests per key, and the split of 401 and 403 responses. A 401 means the key was missing or unknown. A 403 means it was valid but not allowed to do that.
Worked example
A freelancer wires a weather API into a Next.js product page with `?key=a81f` in the client bundle. Two days later the vendor emails: 41,000 calls from IPs in six countries, against a plan of 5,000 a day. Someone copied the key from the page source.
She revokes it, issues a new one, and moves the call into a server route that adds the header. The browser now calls `/api/weather`, and the vendor dashboard shows a single source IP.
How it differs
An API key names an application and usually lives for months. A JWT is a signed token that carries claims such as user id and expiry and can be checked without a database lookup. The key has no built-in expiry or user claims; the JWT has both.
Common errors
Committing the key to a public repo. Shipping it in front-end JavaScript. Sending it in a URL, so it lands in access logs and Referer headers. Using one key for every environment. Never rotating after a contractor leaves.
In practice
This week, search your repos and built bundles for key prefixes, list which keys are still used, and revoke the idle ones. Keep keys in environment variables, scope each to the least access it needs, and set an alert on usage spikes.