What Is an API Token? Definition, Types, and Uses

An API token is a piece of data — usually a long, random string — that a client sends with a request to prove it's allowed to access an API. The server checks the token against its own records (or verifies its signature) and, if it's valid, lets the request through. Think of it as a temporary, revocable pass: instead of sending your username and password on every call, you send a token that represents "this request is authorized."

Tokens exist because passing raw credentials around on every HTTP request is risky and inflexible. A token can be scoped to specific permissions, given an expiration date, and revoked instantly without changing the underlying account password. That's why almost every modern API — REST, GraphQL, or otherwise — uses some form of token-based authentication rather than basic auth.

How API tokens actually work

The typical flow looks like this:

1. You authenticate once (login, signup, or an admin generates a credential for you).
2. The server issues a token — a random string or a cryptographically signed value.
3. Your application stores that token and attaches it to every subsequent API request, almost always in the Authorization header.
4. The server validates the token on each request before processing it.

A standard authenticated request looks like this:

curl https://api.example.com/v1/resource \
  -H "Authorization: Bearer YOUR_TOKEN_HERE"

The word Bearer here is important — it indicates a bearer token, meaning whoever holds it ("bears" it) can use it. There's no additional proof of identity required, which is why protecting the token itself matters as much as protecting a password.

Common types of API tokens

Not all tokens are built the same way. The main categories you'll run into:

• Static API keys — a fixed string generated once and used until revoked. Simple, but less flexible (no built-in expiration or embedded permissions).
• Bearer tokens — sent in the Authorization: Bearer header, often opaque strings issued after login or app registration.
• JWTs (JSON Web Tokens) — self-contained tokens with a signed payload. The server can verify them without a database lookup, and they often carry claims like user ID, scopes, and expiration directly inside the token.
• OAuth access tokens — short-lived tokens issued after an OAuth flow, usually paired with a refresh token so the client can get a new access token without re-authenticating the user.
• Session tokens — tied to a specific login session, often stored in cookies for browser-based apps rather than programmatic API access.

Most SaaS APIs today use a mix: a long-lived API key or token for server-to-server calls, and short-lived OAuth tokens for user-facing integrations.

API token vs API key vs password

These terms get used loosely, but there are real distinctions:

• A password authenticates a person and is meant to be memorized and kept secret indefinitely.
• An API key is usually a static identifier/secret pair issued to an application, often with no built-in expiration.
• An API token is a broader term covering any credential passed with a request — it may be static like a key, or dynamic and short-lived like an OAuth access token or JWT.

In practice, many services call their credentials "API keys" and use them exactly like bearer tokens in the Authorization header — so the line between "key" and "token" is often just terminology, not mechanism.

Why tokens are safer than embedding credentials

Tokens solve a few concrete problems that raw credentials don't:

• Scoping — a token can be limited to read-only access, a specific resource, or a specific rate limit, without touching the underlying account.
• Revocation — you can kill one token without changing the account password or breaking every other integration that uses the same account.
• Expiration — short-lived tokens reduce the damage window if one leaks (a stolen token that expires in an hour is far less dangerous than a password that never changes).
• Auditability — issuing separate tokens per application or team member makes it easy to trace which integration made which request.

Using API tokens in practice

If you're building or consuming an API, a few habits keep tokens from becoming a liability:

• Never hardcode a token in client-side JavaScript or a public repository.
• Store tokens in environment variables or a secrets manager, not in source code.
• Rotate tokens periodically, especially for long-lived server-to-server integrations.
• Use separate tokens per environment (dev, staging, production) so a leak in one doesn't compromise the others.
• Prefer per-application or per-team-member tokens over one shared token, so you can revoke access individually.

This is exactly the model SubToAPI uses for turning Claude access into a programmable API: each application gets its own sub_live_... token, so you can issue, rotate, or revoke access per project or team member without touching anyone else's integration. A request looks like:

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

If you're getting started with token-based APIs, the quickstart guide and the messages endpoint docs walk through generating a token and making your first authenticated call, and pricing covers the available plans if you're evaluating options at signup.

questions

Is an API token the same as an API key? They're closely related and often used interchangeably. An API key is typically a static credential issued to an application, while "API token" is the broader term that also covers dynamic, short-lived credentials like OAuth access tokens and JWTs.

Where should I put my API token in a request? Almost always in the Authorization header, formatted as Authorization: Bearer YOUR_TOKEN. Avoid putting tokens in URL query parameters — they end up in logs, browser history, and referrer headers.

What happens if my API token is leaked? Revoke it immediately from your provider's dashboard and issue a new one. This is why scoping tokens narrowly and setting expirations matters — it limits how much damage a leaked token can do before it's caught and rotated.