What Does an API Key Actually Do?

An API key does three things every time you make a request: it tells the server who is calling, what that caller is allowed to do, and how much of that caller's usage to count. It's a credential, not magic — a string that gets checked against a database record before your request is allowed to proceed.

Concretely, when you attach an API key to a request (usually in a header like Authorization: Bearer sk_live_... or a query parameter), the receiving server does a lookup. It matches the key to an account, checks whether that account has permission for the endpoint you're hitting, checks whether you've hit a rate limit or quota, and then — only if all of that passes — actually runs your request. If any check fails, you get a 401 or 403 back instead of data.

The four jobs an API key performs

Break it down into what actually happens server-side:

• Identification — the key maps to a specific account or application, so the server knows whose request this is.
• Authorization — the account tied to the key has a set of permissions (scopes, plan tier, allowed endpoints). The key inherits those permissions.
• Rate limiting and quota enforcement — most APIs track requests-per-minute or tokens-per-month per key. The server increments a counter on every call and blocks you once you exceed the limit.
• Usage tracking and billing — if the API is metered (pay-per-token, pay-per-call), every request logged against your key feeds into what you owe or what's deducted from a prepaid balance.

None of these require the key itself to be complicated. It's just a lookup value. The intelligence lives in the server-side system that decides what to do once it finds a match.

A concrete example

Here's what a typical authenticated request looks like:

curl https://api.example.com/v1/messages \
  -H "Authorization: Bearer sk_live_abc123" \
  -H "Content-Type: application/json" \
  -d '{"model": "some-model", "messages": [{"role": "user", "content": "hi"}]}'

Behind that single header, the server is doing roughly this:

1. Extract "sk_live_abc123" from the Authorization header
2. Look up which account owns this key
3. Check: is the key active? not revoked? not expired?
4. Check: does this account's plan allow this endpoint/model?
5. Check: has this key exceeded its rate limit this minute?
6. Check: has this account exceeded its monthly quota?
7. If all pass -> process the request
8. Log the request against this key for usage/billing
9. Return the response

That's the entire function of an API key in one flow. It's the single token that lets a stateless HTTP request carry identity and permission with it, instead of requiring a login session or handshake on every call.

Why keys exist instead of just usernames and passwords

You could theoretically authenticate every API call with a username and password, but that's worse in almost every way: passwords are meant to be memorized and rotated by humans, not embedded in scripts or CI pipelines. API keys are built to be:

• Scoped — a key can be limited to read-only access, or to a specific set of endpoints, without touching your main account credentials.
• Revocable independently — you can kill one key without changing your password or breaking other integrations.
• Attributable — if you issue separate keys per environment (dev, staging, prod) or per team member, you can see exactly which key is generating which traffic, which matters a lot when something misbehaves at 2am.
• Machine-friendly — no interactive login flow, no session cookies, just a header on every request.

This is also why leaked API keys are dangerous in a specific way: whoever has the key can do anything the key is authorized to do, immediately, with no further verification. That's the tradeoff for the convenience — treat a key as equivalent to a password, not as a public identifier.

Where this matters for AI API access specifically

If you're integrating an LLM into a product, the API key is doing extra work beyond the basics above. It's usually tied to:

• Which model tier you can call (some plans restrict access to certain models)
• Token-based usage metering, since LLM billing is almost always per-token rather than per-request
• Streaming permissions, since not every key/plan supports server-sent event streams
• Tool-use capability, if the API supports function calling

SubToAPI is built around this exact model: your sub_live_... key is the single credential that authenticates every call to /v1/messages, carries your plan's permissions (streaming, tool use, model access), and drives the usage metadata shown in your dashboard. If you're on a Team or Scale plan, each seat gets its own key, so you can see per-key usage without sharing a single credential across a whole team. Check the quickstart for a five-minute setup, or the messages and streaming docs for what a key unlocks on each endpoint.

Practical takeaways

• Treat every API key like a password: don't commit it to git, don't paste it into client-side JavaScript, don't share it over Slack.
• Use separate keys per environment so a compromised dev key doesn't touch production.
• Check your provider's dashboard regularly for usage per key — a sudden spike is often the first sign of a leaked credential.
• If a key does something you didn't authorize, revoke it immediately rather than trying to "fix" the leak — keys are cheap to regenerate, damage from misuse isn't.

questions

Does an API key work like a password? Functionally, yes — it's a secret string that grants access. The difference is that keys are designed for machines to send on every request, are usually scoped to specific permissions, and can be revoked or rotated independently of your account login.

Can one API key do everything my account can do? Not necessarily. Most APIs let you scope keys — read-only, specific endpoints, specific rate limits — so a key can do a subset of what your account is capable of, not automatically everything.

What happens if I lose or expose my API key? Revoke it immediately from your provider's dashboard and generate a new one. Until you revoke it, anyone with the key can make requests and consume your quota or budget under your identity.