How Do I Use an API Key? A Developer's Guide

The short answer

You use an API key by attaching it to every request you send to an API, usually in an HTTP header, so the server can identify and authenticate your application. Most modern APIs expect the key in an Authorization header formatted as Bearer YOUR_KEY, though some older or simpler APIs accept it as a query parameter or a custom header like X-API-Key.

That's the mechanical answer. The practical answer involves a few more steps: getting the key from the right place, storing it somewhere your code can read without exposing it, and formatting your requests so the API actually accepts it. Below is the full workflow.

Step 1: Get your API key

Every service issues keys differently, but the pattern is consistent: sign up, go to a dashboard or settings page, and generate a key. With SubToAPI, for example, you create an account at /signup, open your dashboard, and generate an application key that looks like sub_live_.... That prefix tells you at a glance which service and environment the key belongs to — useful once you're juggling keys across multiple projects.

Copy the key immediately. Many platforms show the full key only once, then mask it afterward for security.

Step 2: Store the key somewhere safe

Never hardcode a key directly into your source files, especially if that code goes into a Git repository. Use environment variables instead:

export SUBTOAPI_KEY="sub_live_xxxxxxxxxxxxxxxx"

In a Node.js project, load it with process.env:

const apiKey = process.env.SUBTOAPI_KEY;

Add a .env file for local development and make sure it's listed in .gitignore. If you're deploying to a hosting platform (Vercel, Railway, a VPS with systemd, etc.), set the same variable in that platform's environment settings rather than committing it anywhere.

Step 3: Send the key with your request

This is the part people actually mean when they ask "how do I use an API key." You attach it to the request, typically as a header.

curl example:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4",
    "max_tokens": 500,
    "messages": [
      {"role": "user", "content": "Summarize this in one sentence: APIs let software talk to software."}
    ]
  }'

JavaScript (fetch) example:

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: 500,
    messages: [
      { role: "user", content: "Summarize this in one sentence: APIs let software talk to software." }
    ]
  })
});

const data = await response.json();
console.log(data);

Notice the pattern: the key goes in the Authorization header as Bearer <key>, and the actual request body carries your data — in this case a message payload. The full request format for this endpoint is documented at /docs/messages.

Step 4: Handle the response and errors

A successful request returns a JSON body with your result. A failed one almost always returns a 401 or 403 status code with an error message explaining what went wrong. Common causes:

• Missing header — you forgot to include Authorization at all.
• Wrong format — you sent the raw key without the Bearer prefix, or added extra whitespace.
• Expired or revoked key — the key was rotated or deleted in the dashboard.
• Wrong environment — using a test key against a production endpoint, or vice versa.

Always check the status code before parsing the response body. In JavaScript:

if (!response.ok) {
  const err = await response.json();
  console.error("Request failed:", response.status, err);
}

Step 5: Explore what the key unlocks

Once basic authentication works, most APIs support additional capabilities behind the same key — streaming responses, tool calls, and usage metadata are common examples. If you're building something interactive, streaming lets you show output token by token instead of waiting for the full response; see /docs/streaming for the format. If your app needs the model to call external functions, look at /docs/tools. Both use the same key and the same Authorization: Bearer pattern — you're not learning a new auth system, just adding parameters to the request body.

For a full end-to-end setup, including model selection and response formatting, the /docs/quickstart guide walks through a complete first request.

A quick checklist

• Key stored in an environment variable, not hardcoded
• .env file excluded from version control
• Requests include Authorization: Bearer <key> (or the header format your provider specifies)
• Error responses checked and logged, not silently ignored
• Separate keys used for development and production where possible

Following this checklist prevents the two most common problems developers run into: leaked keys in public repositories, and confusing 401 errors caused by a malformed header.

Choosing a plan once you're using keys in production

If you're building something that needs to scale past a single developer account, check what a provider's plans include before you commit. SubToAPI's /pricing page breaks down Solo, Team, and Scale tiers, plus a free trial at signup — worth comparing against your expected request volume and team size before you lock in an integration.

questions

Do I need a different key for every project? It's good practice. Separate keys per project or environment make it easy to revoke access to one integration without breaking others, and they make usage tracking per project much clearer.

What if my API key stops working? Check for expiration, revocation, or a formatting mistake in the header first. If the key is confirmed valid and formatted correctly, check your account dashboard for rate limits or billing issues that might be blocking requests.

Can I use an API key directly in frontend JavaScript? Generally no. Client-side code is visible to anyone who opens dev tools, so API keys called from the browser should go through a backend proxy that holds the key server-side and forwards authenticated requests.