What Is Your API Key? Where to Find It, Explained

When someone asks "what is your API key," they're usually stuck on one of two problems: they don't know what an API key actually looks like for the service they're using, or they can't find where it's stored in their dashboard. This article answers both, using real examples so you can recognize a key on sight and locate it in under a minute.

Your API key is a unique string of characters — usually a mix of letters and numbers, often prefixed with something like sk_, pk_, or in SubToAPI's case sub_live_ — that your application sends with every request to prove who's making the call. It's not your password, it's not your username, and it's not an OAuth token. It's a standalone credential generated specifically for programmatic access, and it lives in your account dashboard, not in your inbox or your head.

What Your API Key Actually Looks Like

Every provider formats keys a little differently, but they share a few traits:

• Long and random. Typically 30–60+ characters, generated by the server, not chosen by you.
• Prefixed. Many services prepend a label so you (and automated secret scanners) can identify the key type at a glance — sub_live_ for SubToAPI, sk_live_ for Stripe, AIza... for some Google APIs.
• Shown once, then hidden. Most dashboards display the full key only at creation time. After that you'll see a masked version like sub_live_••••••••wX9k.
• Tied to an account or project, not a person. The key identifies which account is billed and rate-limited, not which human is typing.

If you're looking at a string that's short, memorable, or something you typed yourself (like a login password), that's not your API key — it's a different credential entirely.

Where to Find Your API Key

The exact location varies by product, but the pattern is almost always the same:

1. Log into the provider's dashboard.
2. Look for a section labeled API Keys, Developer Settings, or Credentials.
3. Either copy the existing key or click Create new key if none exists yet.
4. Store it somewhere safe immediately — most dashboards won't show the full value again.

In SubToAPI, this lives under your account dashboard after you sign up. You generate a key, it's shown once in full, and every request you make afterward authenticates with it via a standard header:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4",
    "max_tokens": 256,
    "messages": [
      {"role": "user", "content": "What is my API key used for?"}
    ]
  }'

The quickstart guide walks through key generation and your first request end to end if you want the exact click path.

API Key vs. Other Credentials You Might Be Confusing It With

This is where most confusion actually comes from — people ask "what is your API key" when they're really looking at a different kind of secret.

| Credential | What it's for | Where it comes from | |---|---|---| | API key | Authenticating server-to-server or app-to-API requests | Generated in a dashboard, one string | | Password | Logging into a human-facing account | Chosen by you | | OAuth token | Delegated, often short-lived access on behalf of a user | Issued after an auth flow, usually expires | | Client ID / Secret | Identifying an app in OAuth flows | Pair of values, not a single key | | Session cookie | Keeping a browser logged in | Set by the server, tied to a browser session |

If your integration guide says "send your API key in the Authorization header" and you're instead sending your account password, that's the mismatch causing your 401 errors.

How It's Actually Used

Once you have it, your API key goes into an HTTP header on every request — almost always Authorization: Bearer <key> or a custom header like X-API-Key. The server checks it against its records, confirms the account is valid and within its usage limits, and processes the request. No key, or an invalid one, and you get a 401 Unauthorized response before your request is even evaluated.

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": 512,
    messages: [{ role: "user", content: "Summarize this ticket." }],
  }),
});

For SubToAPI specifically, the key also determines which seat and plan the request is billed against, which is why keys should never be shared across unrelated projects — the pricing page breaks down how usage maps to Solo, Team, and Scale plans if you're deciding how many keys your team actually needs.

Keeping It Safe Once You've Found It

Finding your key is only step one. A few habits that prevent the most common leaks:

• Never commit it to source control. Use environment variables or a secrets manager.
• Don't paste it into client-side JavaScript. Anything shipped to a browser is publicly readable.
• Rotate it if you suspect exposure. Most dashboards let you revoke and regenerate instantly.
• Use separate keys per environment. Staging and production keys should never be the same string.
• Scope keys narrowly when possible. If a provider supports per-key permissions or rate limits, use them.

If you're building something that needs streaming responses or tool calls on top of Claude, the streaming docs and tool use docs both assume you already have a key in hand — that's the prerequisite before anything else works.

FAQ

Is my API key the same as my password? No. A password authenticates a human logging into a dashboard; an API key authenticates a program making requests. They're generated, stored, and rotated differently, and mixing them up is one of the most common causes of failed integrations.

Where do I find my API key if I've lost it? Go to your provider's dashboard under API Keys or Developer Settings. If the full key isn't shown (most dashboards hide it after creation), revoke the old one and generate a new one rather than trying to recover the original.

Can I use the same API key for multiple apps? Technically yes, but it's not recommended. Separate keys per app or environment make it much easier to track usage, revoke access without breaking everything, and pinpoint the source if a key is ever compromised.