API and API Key: What They Are and How They Relate

API and API Key: The Basics

An API (Application Programming Interface) is a defined way for two pieces of software to talk to each other. An API key is a credential — usually a long random string — that identifies who or what is making a request to that API. The API is the door; the API key is what proves you're allowed to open it.

If you're building or integrating with any web service, you'll interact with both concepts constantly: you call an API endpoint, and you authenticate that call with an API key. This article breaks down what each term actually means, how they fit together in a real request, and the practical decisions you'll face when working with them — naming conventions, security, rotation, and rate limits.

What an API Actually Is

An API defines:

• Endpoints — URLs you send requests to, like https://api.example.com/v1/users
• Methods — HTTP verbs (GET, POST, PUT, DELETE) that describe the action
• Request/response format — usually JSON, with a defined schema for what you send and what you get back
• Authentication requirements — how the server knows the request is legitimate

Most modern web APIs are REST-style over HTTPS, though you'll also see GraphQL, gRPC, and WebSocket-based streaming APIs. Regardless of the shape, the API is essentially a contract: "send me this, in this format, and I'll respond with that."

What an API Key Is

An API key is a token you include with your requests to identify your account, project, or application. It typically looks like a long alphanumeric string, often with a prefix indicating its purpose — for example sub_live_... for a live production key.

API keys usually get passed one of three ways:

# In a header (most common)
Authorization: Bearer sk_live_abc123

# As a custom header
X-API-Key: abc123

# As a query parameter (less secure, avoid when possible)
GET /v1/data?api_key=abc123

Headers are preferred over query parameters because query strings often get logged by proxies, browsers, and analytics tools — leaking your key into places you don't control.

How API and API Key Work Together in a Request

Here's a concrete example. Say you're calling an API to send a message to a language model:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet",
    "max_tokens": 1024,
    "messages": [
      {"role": "user", "content": "Summarize this changelog in 3 bullet points."}
    ]
  }'

Three things happen here:

1. The URL and method (POST /v1/messages) tell the API which operation you want.
2. The body carries the actual payload — the API's defined request format.
3. The Authorization header carries your API key, which the server checks before doing anything else.

If the key is missing, expired, or revoked, the API should reject the request with a 401 Unauthorized before even looking at the body. That's the whole point of separating the API contract from the API key — the contract is public (you can read the docs), but the key is private and scoped to you.

Why API Keys Exist (Beyond "Just Auth")

API keys aren't just a login replacement. They typically also carry:

• Attribution — which project or team made this call, for billing and usage tracking
• Scope — what the key is allowed to do (read-only, specific endpoints, specific models)
• Rate limits — how many requests per minute a given key can make
• Revocability — you can kill one key without touching others, if it leaks

This is why services issue separate keys per application or environment instead of one shared credential. A leaked staging key shouldn't be able to touch production data, and a compromised key for one internal tool shouldn't require rotating every integration you have.

Practical Setup: Calling an API with a Key

Regardless of which API you're using, the pattern is almost always the same:

1. Get a key from the provider's dashboard after signing up.
2. Store it as an environment variable, never hardcoded in source.
3. Send it in the Authorization header on every request.
4. Handle errors for 401 (bad key), 429 (rate limited), and 5xx (server issues).
5. Rotate keys periodically or immediately if one is exposed.

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',
    max_tokens: 512,
    stream: true,
    messages: [{ role: 'user', content: 'Draft a release note for v2.3' }]
  })
});

This same shape — endpoint, headers, JSON body, key in Authorization — applies whether you're calling a payments API, a mapping API, or an LLM API.

A Note on Turning Existing Access into an API

If you already have access to a service through a normal user account (a web app, a chat interface) but need programmatic access with a proper key, streaming, and usage metadata, you generally have two options: build your own auth/proxy layer, or use a service designed for exactly that. SubToAPI does the latter for Claude access specifically — it issues sub_live_... application keys, supports streaming and tool use, and gives you per-key usage data and team seats in a dashboard, starting with a free trial at /signup. If you're evaluating this path, the quickstart and messages docs show the exact request/response shape before you commit.

Questions

Is an API key the same as a password? No. A password authenticates a human logging into an account; an API key authenticates a program calling an API on behalf of an account or project. Keys are usually longer, machine-generated, scoped to specific permissions, and meant to be rotated or revoked without affecting a user's login.

Where should I store my API key? In an environment variable or a secrets manager, never committed to source control or embedded in client-side JavaScript. If a key must be used in a browser, proxy the request through your own backend so the key stays server-side.

What happens if I lose or leak my API key? Revoke it immediately from the provider's dashboard and issue a new one. Update every service that used the old key. This is why per-application keys are preferable to one shared key — a leak only affects the scope of that single key, not your entire account.