API Keys

When Stripe wants to verify that an API request is coming from your application, it uses an API key. When you call the OpenAI API, you include an API key. When Twilio sends an SMS on your behalf, it authenticates your account with an API key.

API keys are long, random strings assigned to a developer account or an application. Include the key in the request header, and the server looks it up to identify the caller, check permissions, and enforce rate limits.

Here is the important distinction: API keys identify applications, not people. A single Stripe API key might be used by a backend service processing charges for millions of customers. The key tells Stripe "this request comes from Merchant Account #1234," not "this request comes from Alice the customer." When you need to know which human is making the request, you use OAuth or JWT. When you need to know which application is making the request, you use API keys.

Every major API-first company uses API keys: Stripe (sk_live_), Twilio (AC + auth token), SendGrid, Mailgun, OpenAI, Anthropic, AWS (access key ID + secret), Google Cloud (API key for public APIs, service account for private ones).

Key format matters. Well-designed API keys communicate information through their prefix:

The sk_ vs pk_ distinction is important. A publishable key can appear in client-side JavaScript because it can only perform limited, non-destructive operations (like creating a Stripe checkout session). A secret key can create charges, issue refunds, and access sensitive data. It must never appear in frontend code, mobile apps, or version control.

How to send the key:

Server-side storage: Store API keys as SHA-256 hashes. If the database is compromised, the attacker gets hashes, not usable keys. This works because API keys have high entropy (256-bit random), so brute-forcing the hash is computationally infeasible. This is different from passwords, which have low entropy and need bcrypt/Argon2 for slow hashing.