How to Generate a Claude API Key Securely

Generating a Claude API key is straightforward — the security part is where most teams get it wrong. This guide covers the actual key generation steps, then the practices that keep that key from ending up in a git history, a client bundle, or a leaked log file.

If you just need the two-minute answer: create the key from your Anthropic Console, store it in an environment variable or secrets manager (never in code), scope access with a proxy or gateway if multiple people or apps need to use it, and rotate it on a schedule. Everything below explains why each step matters and how to implement it.

Step 1: Generate the key in the right place

Anthropic issues keys through the Console under API Keys. Each key is tied to a workspace and organization, so before generating one, decide:

• Who owns this key — an individual, a service, or a specific app
• What it should be allowed to touch — some organizations use separate workspaces per project to isolate usage and billing
• Where it will live — a server, a CI pipeline, a serverless function

Generate the key, copy it once (Anthropic won't show it again), and immediately put it somewhere durable — a password manager or secrets vault — before doing anything else with it. Don't paste it into a chat, a ticket, or a shared doc "just for now." That's how keys leak.

Step 2: Never put the key in client-side code

This is the single most common mistake. If your Claude API key ends up in a browser bundle, a mobile app binary, or a public repo, it will be scraped and abused within hours — API keys get harvested by bots that scan GitHub and public JS bundles continuously.

The fix is architectural: the raw key should only ever exist on a server you control. Your frontend calls your backend, and your backend calls the Claude API (or a gateway in front of it). If you're building a product that issues API access to your own users, you need a second layer of keys — application-level keys that your users hold, which map internally to your real credentials. This is exactly the gap SubToAPI fills: it sits between your Anthropic-based access and your application, issuing scoped sub_live_... keys per app or per customer so the underlying credential is never exposed to end users or client code.

Step 3: Store the key correctly on the server

Once the key lives server-side, how you store it still matters:

# .env (never committed)
CLAUDE_API_KEY=sk-ant-xxxxxxxxxxxxxxxxxxxx

// server.js
const apiKey = process.env.CLAUDE_API_KEY;

if (!apiKey) {
  throw new Error("CLAUDE_API_KEY is not set");
}

Rules that prevent most incidents:

• Add .env to .gitignore before you add the key, not after
• Use your platform's secrets manager in production (AWS Secrets Manager, Vercel/Netlify env vars, Doppler, 1Password Connect) rather than plain environment files on disk
• Never log full request headers or full request bodies that might contain the Authorization header
• Set up a pre-commit hook (like git-secrets or gitleaks) that scans for key patterns before every commit

If you ever do commit a key by accident, treat it as compromised immediately — revoke it in the Console and generate a new one. Removing it from a later commit does not remove it from git history.

Step 4: Limit blast radius with scoped access

A single API key that every developer, script, and environment shares is a single point of failure. If it leaks, everything using it is exposed, and you often can't tell which system caused the leak.

Better patterns:

• Separate keys per environment — one for staging, one for production, so a leaked staging key doesn't touch production data
• Separate keys per service — your web backend and your batch job shouldn't share a key
• Per-application or per-customer keys if you're building something that other people or teams will use through your product

This last case is where raw provider keys stop scaling. If you need to give ten internal teams or external customers their own credentials with independent usage tracking, you don't want to hand out copies of one root key. SubToAPI generates a sub_live_... key per application, so you can revoke one team's access without touching anyone else's, and see usage broken out per key in the dashboard. See /docs/quickstart for how key issuance works.

Step 5: Rotate keys on a schedule, not just after an incident

Rotation shouldn't be a reactive process. A reasonable baseline:

• Rotate production keys every 90 days
• Rotate immediately after any employee or contractor with key access leaves
• Rotate immediately if a key was ever pasted somewhere outside your secrets manager, even briefly

To rotate without downtime: generate the new key, deploy it to your services, confirm requests are succeeding with the new key, then revoke the old one. Keeping both active for a short overlap window avoids a hard cutover failure.

Step 6: Monitor usage for anomalies

A leaked key often shows up first as a spike in usage or requests from unexpected volumes before anyone notices manually. Whatever you use to call the API, make sure you can see:

• Request volume over time, ideally per key
• Token usage and cost per key
• Error rates (a leaked key hitting rate limits is a common early signal)

If you're calling Claude directly, this means building your own logging around every request. If you're routing through a gateway like SubToAPI, usage metadata — tokens, cost, latency — is captured automatically per key in the dashboard, which makes an unusual spike easy to spot without instrumenting it yourself. Streaming responses are covered the same way; see /docs/streaming for details on how metadata is reported for streamed requests.

Quick checklist

• [ ] Generate the key in the Console and store it immediately in a password manager
• [ ] Never embed it in frontend or mobile code
• [ ] Load it from environment variables or a secrets manager, never hardcoded
• [ ] Use .gitignore and a pre-commit secret scanner
• [ ] Use separate keys per environment and per service
• [ ] Rotate on a schedule and after any personnel change
• [ ] Monitor usage per key for anomalies

If you're issuing access to multiple apps or team members, /signup gets you a SubToAPI account with scoped keys and per-key usage tracking out of the box — see /pricing for plan details and /docs for full API reference.

FAQ

Is it safe to store a Claude API key in a .env file? Yes for local development, as long as .env is in .gitignore and never committed. In production, use a secrets manager rather than a plain .env file on a server's disk.

What should I do if I accidentally committed my API key to GitHub? Revoke the key immediately in the Console and generate a replacement. Rewriting git history to remove it is good practice but doesn't undo the exposure — assume it's compromised the moment it's pushed.

Can I give different team members or apps their own API keys instead of sharing one? Yes, and you should. Separate keys per service or team let you revoke and monitor access independently. Tools like SubToAPI generate per-application keys automatically if you need this at scale rather than managing it manually.