To get a Claude API key, sign up at console.anthropic.com (now platform.claude.com), add a payment method, click API Keys in the sidebar, click Create Key, name it, and copy the value immediately. You will not see it again. Then store it in environment variables or a secrets manager, scope it per project, and set a spend cap before you write your first line of code. At Formaum, every client build runs on a scoped Claude API key with spend caps in place from day one.
I use the Claude API every day across client builds. I manage roughly a dozen keys at any given moment, one per project, with separate dev and production keys per workspace. The console part takes two minutes. The part that matters is what you do with the key afterward. Most tutorials end at step five. Here is the full version.
Step 1: Sign up for the Anthropic Console
Go to console.anthropic.com. It redirects to platform.claude.com. Sign up with email, Google, or SSO. You will land in the Anthropic Console, which is a separate product from a Claude Pro or Max subscription. Paying for Claude Pro does not give you API credits, and an API account does not unlock the Claude chat app. They are two different billing surfaces. Know that going in.
New accounts get $5 in free credits. Enough to run a few hundred Sonnet calls and confirm everything works.
Step 2: Add billing and set a spend cap
Before you create the key. Not after. Go to Billing in the left sidebar, add a card, and set a monthly spend limit. Start with $25 if you are exploring, $100 if you are building.
The reason to do this first: a leaked key with no spend cap is a $40,000 incident waiting to happen. Anthropic does not refund runaway usage that you authorized. The cap is the only thing standing between a mistake and your card.
Step 3: Create the key
Click API Keys in the sidebar, then Create Key. Three things to do here.
- Name it descriptively. Not "my key" or "test." Use a pattern like
clientname-projectname-env, for exampleacme-chatbot-dev. When you have ten keys six months from now, the name is the only way you will know what to rotate. - Scope it to a workspace. If you are doing client work, create a separate workspace per client and scope the key to that workspace. Usage, spend, and revocation are all per-workspace. You do not want one client's runaway loop blowing out another client's budget.
- Copy the key immediately. The console shows it once. There is no way to retrieve it later. If you lose it you have to create a new one.
Step 4: Store it safely
This is the step every tutorial hand-waves. A .env file is fine for local development. It is not safe for anything that touches a shared machine, a Git history, or a deploy pipeline.
Local development. Put the key in a project-level .env file and add .env to .gitignore before you write anything else. The order matters. If you commit a key and then add it to .gitignore, the key is still in the Git history forever.
# .env
ANTHROPIC_API_KEY=sk-ant-api03-...
# .gitignore
.env
.env.local
.env.*.local
Production. Do not deploy a .env file. Use a secrets manager. The defaults I reach for:
- Vercel / Netlify: set the key in the project's Environment Variables panel. Scope it to Production only, not Preview, unless you want every PR preview burning your budget.
- Trigger.dev: use environment variables on the project, set per-environment (dev, staging, prod).
- AWS: Secrets Manager or Parameter Store. Inject at runtime.
- Supabase Edge Functions:
supabase secrets set ANTHROPIC_API_KEY=.... - Docker / Kubernetes: never bake the key into the image. Mount it as a secret at runtime.
The rule is the same everywhere. The key never lives in code, never lives in an image, never lives in a config file that ships with the app.
Step 5: Use it in code
The SDKs read ANTHROPIC_API_KEY from the environment automatically. You do not pass it explicitly unless you are handling multiple keys in one process.
Python:
import os
import anthropic
client = anthropic.Anthropic() # reads ANTHROPIC_API_KEY from env
message = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[{"role": "user", "content": "Hello, Claude!"}],
)
print(message.content[0].text)
Node.js:
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic(); // reads ANTHROPIC_API_KEY from env
const message = await client.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 1024,
messages: [{ role: "user", content: "Hello, Claude!" }],
});
console.log(message.content[0].text);
If you ever find yourself writing Anthropic(api_key="sk-ant-...") with a literal key, stop. That is the line that ends up in a Git commit at 2am.
Step 6: Monitor usage and set alerts
The console has a Usage tab. Check it weekly. Two things to watch.
- Per-key spend. If one key is doing 80% of the bill, that is the one to optimize first. Usually it is a prompt with too much context or a retry loop with no backoff.
- Last used timestamp. Any key that has not been used in 30 days should be disabled. Dead keys are leak risk with zero upside.
Set a usage alert at 50% and 80% of your monthly cap. The console supports this directly. If you find out about a runaway loop from your credit card statement, you set the alerts too late.
Key rotation: when and how
Rotate keys on a schedule, not after an incident. My defaults:
- Production keys: every 90 days.
- Dev keys: every 180 days or when a teammate leaves.
- Any key that touched a public repo, a screenshot, a video, or a screen-share: immediately. No grace period.
The rotation pattern: create the new key, deploy it to the secrets manager, verify the app is using the new key in logs, then disable the old key in the console. Disable first, delete a week later. Disabling is reversible. Deleting is not, and you will occasionally find a cron job nobody told you about that was using the old one.
Common mistakes
- Committing the key. The single most common leak. GitHub's secret scanning will catch it and Anthropic will auto-revoke, but assume the key is burned the moment it hits the history.
- No spend cap. A loop bug with no cap can spend hundreds of dollars an hour. Set the cap before you write code.
- One key across every project. When you have to revoke it, you take down everything. One key per project, minimum.
- Sharing keys across teammates. Each person on the team gets their own key under their own user. When they leave, you revoke one key, not eight.
- Hardcoding the key in client-side code. If the key ships to a browser, it is public. All Claude API calls must run server-side or through a proxy.
- Skipping the workspace step. Putting everything in the default workspace makes per-client billing a nightmare at year-end.
What good looks like
One key per project. Scoped to its own workspace. Stored in a secrets manager, never in code or a committed file. Spend cap on the account, alerts at 50 and 80 percent. Rotation on a calendar reminder, not in response to a leak. Usage reviewed weekly. That is the full setup. The console part takes two minutes. The rest is what separates a hobby script from something you trust at 3am on a Tuesday when nobody is watching.
Run on a stack that's holding you back?
Book a 45-minute discovery call. I'll map what moves, what stays, and what makes sense for your operation.
Book a call