Claude API Key Environment Variables Setup Guide

Why Your Claude API Key Belongs in an Environment Variable

If you're building anything with Claude — a script, a backend service, a serverless function — the key question is always the same: where do you put the API key so it works reliably but never ends up in your Git history? The answer is an environment variable. You set it once in your shell, .env file, or deployment platform, then read it in code with something like process.env.ANTHROPIC_API_KEY or os.environ["ANTHROPIC_API_KEY"]. The key never appears in your source files, which means it can't accidentally get committed, logged, or shared.

This guide walks through exactly how to set that variable on macOS, Linux, and Windows, how to load it from a .env file during local development, and how to keep it safe in production. The same approach applies whether you're calling Anthropic's API directly or using an API key issued by a proxy service like SubToAPI, which turns your Claude access into a standard sub_live_... key you authenticate with the same way.

Setting the Variable on macOS and Linux

The fastest way to test something is exporting the variable directly in your terminal session:

export ANTHROPIC_API_KEY="sk-ant-xxxxxxxx"

This only lasts for the current shell session. To make it permanent, add the line to your shell's config file — ~/.zshrc for zsh (the default on modern macOS) or ~/.bashrc for bash on most Linux distributions:

echo 'export ANTHROPIC_API_KEY="sk-ant-xxxxxxxx"' >> ~/.zshrc
source ~/.zshrc

Verify it's set correctly:

echo $ANTHROPIC_API_KEY

If you're using SubToAPI instead, the variable name is just a naming convention — call it whatever your code expects, for example:

export SUBTOAPI_KEY="sub_live_xxxxxxxx"

Setting the Variable on Windows

On Windows, PowerShell and Command Prompt handle environment variables differently from Unix shells.

PowerShell (current session only):

$env:ANTHROPIC_API_KEY = "sk-ant-xxxxxxxx"

PowerShell (persistent, across sessions):

[System.Environment]::SetEnvironmentVariable("ANTHROPIC_API_KEY", "sk-ant-xxxxxxxx", "User")

Command Prompt:

setx ANTHROPIC_API_KEY "sk-ant-xxxxxxxx"

After using setx, close and reopen your terminal for the change to take effect — it doesn't apply to the window you ran it in.

Using a .env File for Local Development

Exporting variables manually every time you open a new terminal gets tedious. The standard pattern for local projects is a .env file in your project root, loaded automatically by a library like dotenv.

Create a .env file:

ANTHROPIC_API_KEY=sk-ant-xxxxxxxx
SUBTOAPI_KEY=sub_live_xxxxxxxx

In Node.js, install and use dotenv:

npm install dotenv

import "dotenv/config";

const response = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: `Bearer ${process.env.SUBTOAPI_KEY}`
  },
  body: JSON.stringify({
    model: "claude-sonnet-4",
    max_tokens: 1024,
    messages: [{ role: "user", content: "Hello" }]
  })
});

In Python, use python-dotenv:

pip install python-dotenv

import os
from dotenv import load_dotenv

load_dotenv()
api_key = os.environ["SUBTOAPI_KEY"]

Critical step: add .env to your .gitignore file immediately, before you ever commit it:

echo ".env" >> .gitignore

If you've already committed a .env file at some point, assume the key inside it is compromised. Rotate it and remove the file from your Git history with a tool like git filter-repo — simply deleting it in a new commit leaves it recoverable in the history.

Loading Environment Variables in Production

Local .env files don't deploy with your app in most setups — and they shouldn't. Production platforms have their own mechanism for injecting secrets:

• Vercel / Netlify: set variables in the project dashboard under Environment Variables; they're injected at build and runtime.
• Docker: pass them with -e ANTHROPIC_API_KEY=sk-ant-xxx or an --env-file flag, never baked into the image.
• GitHub Actions: store them as repository secrets and reference them as ${{ secrets.ANTHROPIC_API_KEY }}.
• Heroku / Railway / Render: set them through the dashboard or CLI config vars command.

The principle is identical everywhere: the key lives in the platform's secret store, not in your code or your Dockerfile.

A Quick Sanity Check Before You Ship

Once your variable is set, confirm your code can actually read it before debugging anything else:

if (!process.env.SUBTOAPI_KEY) {
  throw new Error("SUBTOAPI_KEY is not set");
}

This one check saves you from the most common failure mode: a request that fails with a 401 not because the key is wrong, but because it was never loaded at all. If you're working with SubToAPI, the quickstart guide and Messages API reference both show working request examples you can diff against your own setup, and streaming docs cover the same env var pattern for SSE connections.

Best Practices Worth Following

• Use separate keys for development and production so a leaked dev key doesn't expose production traffic.
• Never print the full key in logs — log the last four characters at most, if you need confirmation it loaded.
• Rotate keys periodically and immediately after any suspected exposure.
• If you're managing a team, give each developer their own key or seat rather than sharing one variable across machines — SubToAPI's team plan is built around per-seat keys for exactly this reason.

Questions

Do I need to restart my terminal after setting an environment variable? On macOS/Linux, running export applies immediately to the current session; new sessions need the variable added to your shell config file. On Windows, setx requires a new terminal window to take effect.

Can I use a .env file in production? It's not recommended. Most hosting platforms provide their own secret management, and relying on a .env file risks it being included in a build artifact or container image by mistake.

What's the difference between ANTHROPIC_API_KEY and a SubToAPI key? They're both environment variables holding a bearer token, just issued by different services. A SubToAPI key (sub_live_...) is created at signup and works the same way — read it from the environment and send it as Authorization: Bearer $SUBTOAPI_KEY.