API key
A secret string sent with each request that identifies the calling account. It is the simplest workable form of API authentication and the foundation for quotas, limits and billing.
An API key answers one question on every request: who is this? Without an answer, nothing else in an API product can exist, because you cannot meter, limit, or bill an anonymous caller.
Send it in a header, conventionally something like x-api-key or an Authorization header. Not in the query string, where it ends up in server access logs, browser history, proxy logs, and referrer headers. That single choice prevents a whole category of accidental credential exposure.
What a key system needs beyond simply checking a string:
- Multiple keys per account, so a customer can rotate without downtime and keep staging separate from production.
- Immediate revocation, not revocation at the next cache expiry.
- A last-used timestamp, which is what lets you tell a customer that the key they are worried about has been idle for months.
- Hashed storage. Store a hash, show the full value once at creation. If your dashboard can display an existing key in full, so can anyone who reaches your database.
- A visible prefix, such as the first eight characters, so a key can be identified in a list and in logs without exposing the secret.
A key is not the right tool for everything. When a third party needs to act on behalf of an end user, OAuth exists for that reason, and the consent flow is the point. For server to server access to your own data API, a key is the correct amount of machinery, and it ships today.
Once identity is solved, the rest of the product attaches to it: a quota counts what the key consumed, a rate limit constrains how fast it consumes, and every log line can be attributed to an account rather than an IP address. Give each key only the access its job needs, so a leaked read key cannot write.