How to Generate an Anthropic API Key for Your App

Generating an Anthropic API key means creating a unique credential in the Anthropic Console that authenticates your requests to Claude's API. You need one any time you want to call Claude programmatically — from a script, a backend service, a mobile app, or a CI pipeline — rather than through the claude.ai chat interface.

The process itself takes under five minutes, but there are a few decisions around billing, key scoping, and storage that matter more than the generation step itself. This guide covers all of it, plus what to do if direct API access doesn't fit your situation.

Step 1: Create an Anthropic account

Go to the Anthropic Console and sign up with an email address or an SSO provider (Google, GitHub). If you already use Claude.ai, note that your consumer account and your API/Console account are separate — a claude.ai login doesn't automatically give you API access.

Step 2: Add a payment method

Anthropic's API is prepaid or invoiced usage, billed per token, separate from any Claude Pro subscription. Before you can generate a working key, you'll usually need to add a credit card and, for testing, load a small amount of credit. Without billing set up, some accounts can generate a key but every request will fail with a billing/permission error — so if your first call bounces, check billing before assuming the key is broken.

Step 3: Generate the key

Inside the Console:

1. Open the API Keys section (sometimes under Settings or Organization settings depending on account type).
2. Click Create Key.
3. Give it a descriptive name — something tied to its purpose, like prod-backend or ci-tests, not just "key1". You'll thank yourself later when you have five keys and need to revoke one.
4. Copy the key immediately. It's shown once; Anthropic doesn't store the full plaintext for you to view again later.

The key will look something like sk-ant-api03-.... Store it somewhere safe before closing the tab.

Step 4: Store it correctly

Never hardcode the key into source files that get committed to git. Use environment variables:

export ANTHROPIC_API_KEY="sk-ant-api03-..."

And reference it in code rather than pasting it inline:

const apiKey = process.env.ANTHROPIC_API_KEY;

const response = await fetch("https://api.anthropic.com/v1/messages", {
  method: "POST",
  headers: {
    "x-api-key": apiKey,
    "anthropic-version": "2023-06-01",
    "content-type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-sonnet-4",
    max_tokens: 1024,
    messages: [{ role: "user", content: "Hello, Claude" }]
  })
});

If you're deploying to a server or a serverless platform, use that platform's secrets manager (Vercel env vars, AWS Secrets Manager, Doppler, etc.) rather than a .env file that might end up in a build artifact.

Step 5: Test the key

Run a minimal request before wiring it into your app. A failed test at this stage almost always means one of three things: billing isn't set up, the key was copied with a trailing space, or you're hitting a rate limit on a brand-new account. Anthropic's error messages usually tell you which one.

Generating keys for multiple environments

Most teams end up with at least three keys: one for local development, one for staging, one for production. Generate each separately rather than reusing a single key everywhere — it lets you revoke a compromised dev key without taking down production, and it gives you per-environment usage visibility in the Console.

If you have multiple developers, each person generating their own key (rather than sharing one) makes it much easier to see who's driving usage and to revoke access when someone leaves the project.

When generating your own key isn't the right move

Direct API keys work well for a single developer building a single project. They get harder to manage once you have:

• A product with multiple users, each of whom needs isolated usage — you don't want one shared Anthropic key behind your whole customer base with no per-user attribution.
• A team that needs to see who's spending what, without giving everyone billing access to the Anthropic account.
• A need for per-application keys you can issue and revoke independently, separate from your one Anthropic account credential.

This is the gap SubToAPI fills. It sits on top of your existing Claude access and lets you generate scoped application API keys (sub_live_...) instead of distributing one raw Anthropic key. Each key gets its own usage metadata, and streaming, tool use, and team seats are managed from a single dashboard. You can sign up and generate your first sub_live_ key in a couple of minutes, and the quickstart walks through your first request. If you're comparing setups, pricing covers the Solo, Team, and Scale plans.

Rotating and revoking keys

Once a key exists, treat it like a password. If you suspect it leaked — pushed to a public repo, pasted in a support ticket, exposed in a client-side bundle — revoke it immediately from the Console and generate a replacement. Client-side JavaScript should never hold an Anthropic key directly, since anyone can read it from the browser; keys belong in server environments or behind a proxy that authenticates your own users separately.

Quick checklist

• Account created and billing added
• Key generated with a descriptive name
• Key stored in an environment variable or secrets manager, not in code
• Test request confirms the key works
• Separate keys used for dev, staging, and production
• A plan for rotating or revoking keys if they leak

questions

Do I need a Claude Pro subscription to generate an API key? No. API access and Claude.ai subscriptions are billed and managed separately. You can have an API key without any Claude.ai plan, and vice versa.

Why does my newly generated key return a permission error? Almost always missing or unconfirmed billing. Add a payment method and, if required, load a small amount of prepaid credit, then retry the same key.

Can I generate multiple API keys on one Anthropic account? Yes — most teams generate separate keys per environment (dev, staging, production) or per developer so usage and revocation can be managed independently.