What Is the API Key in a Request? A Practical Answer

An API key is a unique string of characters that identifies who or what is calling an API. It gets attached to every request — usually in a header, sometimes in a query string — and the server checks it before deciding whether to process the request and how to bill or rate-limit it. That's the whole idea: a credential that says "this request comes from account X" without requiring a full login flow.

If you've landed here because you're staring at a dashboard trying to figure out which value is "the" API key, it's typically the long alphanumeric string, often prefixed with something like sk_, pk_, or a vendor-specific tag, that you're told to keep secret and paste into your code as a header value. It's not your username, not your password, and not a session token — it's a standalone credential designed specifically for machine-to-machine authentication.

Where the API key actually lives in a request

Most modern APIs send the key in an HTTP header. The two most common patterns:

Authorization: Bearer YOUR_API_KEY

X-API-Key: YOUR_API_KEY

Some older or simpler APIs accept the key as a query parameter (?api_key=YOUR_API_KEY), but that's less common now because query strings end up in server logs, browser history, and proxy caches — all places a secret shouldn't sit.

Here's what a request looks like with SubToAPI, which uses the Authorization: Bearer pattern with keys prefixed sub_live_:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4",
    "max_tokens": 200,
    "messages": [{"role": "user", "content": "Explain what an API key does."}]
  }'

The server reads that header, matches sub_live_... against an account, confirms it's valid and not revoked, and only then runs the request. If the header is missing or the key is wrong, you get a 401 back before any real work happens.

What the API key is actually doing behind the scenes

When a request hits the server, three things typically happen in order:

1. Authentication — does this key exist and is it active? This answers "who is calling."
2. Authorization — what is this key allowed to do? A key scoped to read-only access shouldn't be able to trigger writes or deletes.
3. Accounting — usage against this key gets logged: request counts, tokens consumed, error rates. This is how rate limits, quotas, and billing get tied to a specific account or even a specific application within an account.

This is why "the API key" is more than a password substitute. A password proves identity for a human logging into an account. An API key proves identity and carries metadata — plan tier, rate limit, permissions, usage history — that the server needs on every single call, often thousands of times a minute.

API key vs. other credentials you'll run into

• Password — for humans, tied to a login session, usually paired with 2FA.
• OAuth access token — short-lived, tied to a specific user's delegated permissions, refreshed via a refresh token. Common when an app acts on behalf of a third-party user.
• API key — long-lived (until rotated or revoked), tied to an application or account rather than a specific human session, no refresh flow needed.

API keys are simpler to implement than OAuth, which is exactly why most backend-to-backend integrations — a server calling another server — use them instead of a full OAuth dance. You don't need a browser redirect or a consent screen; you just need the string in a header.

Why the key format usually includes a prefix

You'll notice most modern API keys aren't random gibberish — they start with something like sk_live_, pk_test_, or sub_live_. That prefix isn't decorative. It lets:

• Automated secret scanners (GitHub, GitGuardian, etc.) recognize the pattern instantly if a key is accidentally committed to a public repo.
• Developers tell at a glance whether they're looking at a live key or a test/sandbox key.
• Support teams identify which service a leaked key belongs to without asking.

If you're managing access to Claude through SubToAPI, every application key follows the sub_live_... format, and you can generate, label, and revoke them individually from the dashboard — so a key leaked in one app doesn't force you to rotate credentials everywhere. Details on generating and using keys are in the quickstart guide.

Practical rules for handling an API key

• Never hardcode it in source. Use environment variables ($SUBTOAPI_KEY, process.env.API_KEY) and load them at runtime.
• Never put it in client-side JavaScript. Anything shipped to a browser is visible to anyone who opens dev tools. API keys belong on the server.
• Scope it if the provider allows it. One key per application or environment (dev, staging, prod) makes it obvious what to revoke when something goes wrong.
• Rotate it periodically, and immediately if you suspect exposure — a commit history leak, a log file that got shared, a screenshot in a support ticket.
• Check usage regularly. A sudden spike in requests on a key you didn't touch is usually the first sign it's been compromised.

A quick JavaScript example showing the key loaded from environment rather than hardcoded:

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-sonnet-4",
    max_tokens": 200,
    messages: [{ role: "user", content: "Summarize this article in one line." }]
  })
});

(Note the trailing quote typo above is just illustrative — in real code, keep your JSON keys properly quoted.)

If you're setting up API access for the first time, SubToAPI turns an existing Claude account into a proper HTTPS API with per-application keys, streaming support, and usage tracking baked in — no need to build your own key management layer from scratch. You can see the full request format in the Messages API docs or start with a free trial at signup.

questions

Is an API key the same as a token? Not exactly. An API key is usually long-lived and tied to an account or app, while a token (like an OAuth access token) is typically short-lived, scoped to a specific user session, and refreshed periodically. Both authenticate requests, but tokens carry an expiry by design.

Where do I find my API key? It's generated inside the provider's dashboard after signup, usually under a "Keys" or "API" section. With SubToAPI, you create keys per application in the dashboard after your trial starts, and each one is shown only once in full for security.

What happens if my API key gets leaked? Revoke it immediately from the provider's dashboard and generate a new one. Update any environment variables or config files referencing the old key, and check the usage logs for unexpected activity during the exposure window.