How to Set an API Key: The Complete Setup Guide

Setting an API key means making a secret credential available to your application so it can authenticate requests to a service — without hardcoding it into your source code. In practice, this comes down to three common methods: environment variables, configuration files, or request headers set directly in your code. The right choice depends on where your code runs and how sensitive the key is.

This guide walks through each method, when to use it, and the mistakes that get keys leaked or rejected.

Method 1: Environment Variables (Recommended)

Environment variables are the standard way to set an API key because they keep secrets out of your codebase and version control.

On macOS/Linux (temporary, current shell session):

export SUBTOAPI_KEY="sub_live_xxxxxxxxxxxxxxxx"

On macOS/Linux (permanent): add the line above to ~/.zshrc, ~/.bashrc, or ~/.profile, then reload with source ~/.zshrc.

On Windows (PowerShell):

$Env:SUBTOAPI_KEY="sub_live_xxxxxxxxxxxxxxxx"

For a permanent setting on Windows, use setx SUBTOAPI_KEY "sub_live_xxxxxxxxxxxxxxxx" and open a new terminal for it to take effect.

In a .env file (used with libraries like dotenv):

SUBTOAPI_KEY=sub_live_xxxxxxxxxxxxxxxx

require('dotenv').config();
const apiKey = process.env.SUBTOAPI_KEY;

Always add .env to your .gitignore file before your first commit. Committing a .env file with a real key is the single most common way API keys end up leaked on GitHub.

Method 2: Setting the Key in Code

Sometimes you need to set the key directly, especially in scripts, serverless functions, or when testing. Read it from the environment rather than hardcoding it as a string:

const apiKey = process.env.SUBTOAPI_KEY;

if (!apiKey) {
  throw new Error("Missing SUBTOAPI_KEY environment variable");
}

Avoid writing the raw key as a literal string in a file that gets committed. If you must test something quickly, delete the key from the file before saving, or use a throwaway key you can revoke afterward.

Method 3: Setting the Key in an HTTP Request Header

Most modern APIs, including SubToAPI, expect the key in an Authorization header using the Bearer scheme. This is where the key actually gets "used" once it's been set as a variable:

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

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",
    messages: [{ role: "user", content: "Hello" }]
  })
});

The key never appears as a literal in the code — it's pulled from the environment at runtime, sent once in the header, and never logged or stored.

Setting Keys in Cloud and CI Environments

If you're deploying to a hosting platform, you generally set environment variables through the platform's dashboard or CLI rather than a .env file:

• Vercel/Netlify: Project settings → Environment Variables
• GitHub Actions: Repository → Settings → Secrets and variables → Actions, then reference with ${{ secrets.SUBTOAPI_KEY }}
• Docker: pass with docker run -e SUBTOAPI_KEY=sub_live_xxxx or use a --env-file
• AWS Lambda / serverless: configure environment variables in the function's configuration, not in the deployment package

The principle is the same everywhere: the key lives outside your code, injected at runtime by the platform.

Getting an API Key in the First Place

Before you can set a key, you need one. If you're turning your existing Claude access into an API you can call from your own apps, sign up for SubToAPI and generate a key from the dashboard — keys are prefixed sub_live_ so you can identify them at a glance in logs or billing exports. The quickstart guide walks through generating your first key and making a test request in under five minutes.

Common Mistakes When Setting an API Key

• Hardcoding the key as a string literal in a file that gets pushed to a public or shared repository.
• Forgetting to restart your terminal or app after setting an environment variable — changes to shell config files only apply to new sessions.
• Using the wrong variable name — a typo like SUBTOAPI_KEY vs SUB_TO_API_KEY will silently fail with an authentication error rather than a syntax error.
• Mixing up test and live keys across environments, which causes requests to fail or bill the wrong account.
• Not scoping keys per application — using a single key everywhere makes it hard to know which app to blame when something breaks, and harder to revoke access for just one integration. SubToAPI lets you generate separate application keys under one account, so you can rotate or revoke one without affecting the rest (see pricing for seat-based plans if you're setting this up for a team).

Verifying the Key Is Set Correctly

Before wiring it into your app, confirm the variable is actually available:

echo $SUBTOAPI_KEY

If that prints nothing, the export didn't take effect in the current session — re-run the export command or open a new terminal window. Then confirm the API itself accepts it by making a minimal request, as shown in the Messages API docs.

FAQ

Where should I store an API key so it's not exposed in my code? Use an environment variable, ideally loaded from a .env file that's excluded from version control via .gitignore, or set through your hosting platform's secrets manager for production deployments.

How do I set an API key permanently instead of just for one terminal session? Add the export line to your shell's startup file (~/.bashrc, ~/.zshrc) on macOS/Linux, or use setx on Windows. Restart your terminal afterward for the change to apply.

Why is my request still failing after I set the API key? Check that the variable name matches exactly what your code expects, that you restarted the terminal or process after setting it, and that the key is being sent in the correct header format — typically Authorization: Bearer <key>.