What Is an API Key? A Clear, Practical Definition
An API key is a unique string of characters that identifies who (or what application) is making a request to an API. It works like a password for software: instead of a human typing a username and password into a login form, a program sends the key with every request, and the server checks it before doing any work.
In practice, an API key answers two questions for the server: is this request allowed to happen, and who should be billed or blamed for it. That's the whole idea. It's not a complex protocol — it's a token, usually 20 to 60 characters long, that you generate once in a dashboard and then reuse in your code.
What an API key actually looks like
Most API keys are random alphanumeric strings, often prefixed so you can identify what service they belong to at a glance. Examples of the pattern (not real keys):
sk_live_4f8a2b91c3d0e5f6...
sub_live_9a1b2c3d4e5f6789...
AIzaSyD-9tSrke72PouQMnMX...
The prefix (sk_, sub_live_, etc.) tells you the provider and sometimes the environment (live vs test). The rest is cryptographically random, generated server-side so it can't be guessed.
How an API key is used in a request
You attach the key to each HTTP request, almost always in a header. The two most common patterns:
As a bearer token in the Authorization header:
curl https://api.subtoapi.app/v1/messages \
-H "Authorization: Bearer $SUBTOAPI_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "claude-3-5-sonnet",
"messages": [{"role": "user", "content": "Hello"}]
}'
As a custom header:
curl https://api.example.com/v1/data \
-H "X-API-Key: your_key_here"
The server receives the request, looks up the key, confirms it's valid and active, checks what it's allowed to do, and either processes the request or returns a 401 Unauthorized / 403 Forbidden error.
What an API key is for
At a technical level, an API key serves three purposes:
- Authentication — proving the request comes from a registered account or application, not an anonymous stranger.
- Authorization — determining what that account is allowed to do (which endpoints, which models, which rate limits).
- Attribution and billing — tracking usage per key so providers can meter requests, tokens, or API calls and charge accordingly.
This is why almost every paid API — from cloud infrastructure to AI models to payment processors — requires one. Without it, there's no way to tell requests apart or stop someone from hammering your service for free.
API key vs. other authentication methods
API keys are the simplest form of API authentication, but not the only one:
| Method | How it works | Typical use case | |---|---|---| | API key | Single static token sent with each request | Server-to-server calls, internal tools, SaaS APIs | | OAuth 2.0 | Token issued after a login/consent flow, often short-lived | Apps acting on behalf of a user (e.g. "Sign in with Google") | | Basic Auth | Username + password encoded in the header | Legacy systems, internal services | | JWT (signed token) | Token contains claims and is cryptographically signed | Session management, microservices |
API keys win on simplicity: no redirect flows, no token refresh logic, just a string you generate once and use everywhere. That's why most developer-facing APIs — including AI model APIs — default to them.
Test keys vs. live keys
Many providers issue two flavors of key:
- Test/sandbox keys hit a mock or non-billed environment, useful during development.
- Live/production keys hit the real service and count toward usage and billing.
Mixing them up is a common source of confusing bugs — a request that "works" in testing but returns unexpected data or errors in production, or vice versa. Always check which environment a key belongs to before debugging further.
Basic security practices for API keys
Because a key is effectively a password, it deserves the same care:
- Never commit keys to source control. Use environment variables (
$SUBTOAPI_KEY,process.env.API_KEY) and add.envfiles to.gitignore. - Don't expose keys in frontend code. Anything shipped to a browser can be read by anyone. Keep keys server-side and proxy requests through your own backend if the frontend needs API access.
- Rotate keys periodically and immediately if you suspect a leak.
- Scope keys narrowly if the provider supports it — a key limited to read-only access or a single project limits the damage if it's compromised.
- Revoke unused keys. Old keys from abandoned projects are a common source of unnoticed exposure.
If you're integrating an AI model API, for example, SubToAPI issues sub_live_... application keys from your dashboard so you can generate, rotate, and revoke them per project without ever exposing your underlying Claude account credentials. See the quickstart guide for the exact request format, or pricing if you're evaluating plans.
A minimal working example
Here's the full lifecycle in code — generate a key in a dashboard, store it as an environment variable, and use it in a request:
// server.js
const response = await fetch("https://api.subtoapi.app/v1/messages", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
model: "claude-3-5-sonnet",
messages: [{ role: "user", content: "Summarize this text." }]
})
});
const data = await response.json();
console.log(data);
The key never appears in the code itself — it's pulled from the environment, which is the standard pattern for keeping credentials out of your repository. For streaming responses or tool use, the request shape is similar; see /docs/streaming and /docs/tools for details.
questions
Is an API key the same as a password? Functionally, yes — it's a secret credential that proves who's making a request. The difference is that API keys are meant for programs, not humans, and typically don't require a username alongside them.
Where do I get an API key? You generate one from the provider's dashboard after creating an account. For SubToAPI, you sign up at /signup, create a key in the dashboard, and use it immediately with any endpoint documented at /docs.
What happens if my API key leaks? Anyone with the key can make requests as you, potentially running up usage or accessing data. Revoke the key immediately in your dashboard, generate a new one, and update it everywhere it's used.