Claude API Environment Variables Setup Guide

If you're integrating Claude into an application, the first real decision you'll make isn't about prompts or models — it's how you store and load your API key. Get this wrong and you either leak credentials into a public repo or spend an afternoon debugging why process.env.ANTHROPIC_API_KEY is undefined in production. This guide walks through setting up Claude API environment variables correctly across local development, CI/CD, and production deployments.

The short answer: store your key in a .env file locally (never committed), load it with a library like dotenv, reference it in code as an environment variable rather than a hardcoded string, and set the same variable name in your hosting provider's dashboard or secrets manager for production. The rest of this article covers the details that trip people up — naming conventions, multiple environments, rotation, and what changes if you're using a proxy layer like SubToAPI instead of calling the raw Anthropic API.

Why environment variables matter for API keys

Hardcoding an API key directly in your source file works for a five-minute test script. It fails the moment you:

• Commit the file to Git (even a private repo is a risk — contributors, leaked backups, accidental public forks)
• Need different keys for staging vs. production
• Want to rotate a compromised key without editing and redeploying code
• Run the same codebase across multiple environments (local, CI, serverless, containers)

Environment variables solve all of this by separating configuration from code. The code references a name; the actual value lives outside the repository, injected at runtime.

Step 1: Create a local .env file

In your project root, create a .env file:

ANTHROPIC_API_KEY=sk-ant-xxxxxxxxxxxxxxxxxxxx

If you're calling Claude through SubToAPI instead of directly, your variable will hold a sub_live_ key instead:

SUBTOAPI_KEY=sub_live_xxxxxxxxxxxxxxxxxxxx

Immediately add .env to your .gitignore:

.env
.env.local
.env.*.local

Most frameworks (Next.js, Express with dotenv, Vite, Django via python-dotenv) will auto-load this file in development. For Node.js specifically:

npm install dotenv

import 'dotenv/config';

const apiKey = process.env.SUBTOAPI_KEY;

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

That early check matters — failing fast with a clear error message saves debugging time versus a cryptic 401 three function calls later.

Step 2: Use consistent naming across environments

Pick one naming convention and stick to it everywhere: local, CI, staging, production. Common patterns:

• ANTHROPIC_API_KEY if calling Claude directly
• SUBTOAPI_KEY if calling through SubToAPI's HTTPS endpoint
• Prefix with environment when you need multiple keys side by side, e.g. SUBTOAPI_KEY_STAGING, SUBTOAPI_KEY_PROD

Avoid variable name drift between environments — a key named CLAUDE_KEY locally and ANTHROPIC_API_KEY in production is a guaranteed deploy-day bug.

Step 3: Set variables in your deployment target

Every hosting provider has a secrets/environment settings panel. The pattern is identical: add the variable name and value, scoped to the right environment (preview vs. production matters on platforms like Vercel or Netlify).

Example for a generic Node server using a process manager:

export SUBTOAPI_KEY=sub_live_xxxxxxxxxxxxxxxxxxxx
node server.js

For Docker, pass it at runtime rather than baking it into the image:

docker run -e SUBTOAPI_KEY=sub_live_xxxxxxxxxxxxxxxxxxxx myapp

Never put real keys in a Dockerfile with ENV — that value gets baked into the image layer and anyone with image access can extract it.

Step 4: Separate keys per environment

Use different keys for development, staging, and production. If you're on SubToAPI, each key is scoped under your account with its own usage metadata, so you can tell at a glance whether a spike in calls came from a staging script left running overnight or real production traffic. Create separate keys per environment or per team member from the dashboard after /signup, rather than sharing one key across everything.

Step 5: Verify the setup with a real request

Once your variable is loaded, test it against a live endpoint before wiring it into your app logic:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-4",
    "max_tokens": 100,
    "messages": [{"role": "user", "content": "Say hello in one sentence."}]
  }'

If this returns a response, your environment variable is correctly set and readable at runtime. If you get an authentication error, check for trailing whitespace in the .env file, a missing export, or the variable not being passed into the container/process scope. The full request format is in /docs/messages, and a complete setup walkthrough including streaming is in /docs/quickstart.

Common mistakes to avoid

• Committing .env before adding it to .gitignore. If this already happened, rotate the key immediately — removing the file later doesn't erase it from Git history.
• Quoting values unnecessarily. Most .env parsers treat KEY=value and KEY="value" differently depending on the library; keep it simple and unquoted unless the value contains spaces.
• Loading .env in production. Production environments should use the platform's native secrets manager, not a bundled .env file — fine for local dev, risky for deployed code.
• Forgetting serverless cold starts. On serverless platforms, environment variables are injected at deploy time, not runtime — if you change a key, redeploy, don't just wait.

FAQ

What's the difference between ANTHROPIC_API_KEY and a SubToAPI key as environment variables?

Functionally identical — both are just strings read from process.env (or your language's equivalent) and passed in an Authorization header. The difference is what they unlock: a raw Anthropic key talks to Anthropic directly, while a SubToAPI key (sub_live_...) routes through SubToAPI's endpoint, which adds streaming helpers, tool use, usage metadata, and team seat management on top. See /docs for the full comparison.

Should I use .env files in production?

No. Use your hosting provider's environment variable settings or a dedicated secrets manager (AWS Secrets Manager, Vault, Doppler). .env files are convenient for local development but aren't designed for production-grade secret rotation or access auditing.

How do I rotate a Claude API key without downtime?

Generate a new key first, update the environment variable in staging, verify it works, then update production and redeploy. Only revoke the old key after confirming the new one is live in all environments. If you're managing multiple team members' keys, a dashboard with per-seat keys (available on SubToAPI's Team and Scale plans — see /pricing) makes rotating one person's access without touching everyone else's much simpler.