Anthropic API Base URL: What It Is and How to Use It

The Short Answer

The Anthropic API base URL is https://api.anthropic.com. It's the root domain every request to Claude's API goes to, before you append a versioned path like /v1/messages. So a full request URL looks like https://api.anthropic.com/v1/messages, and that's the endpoint the official Python and TypeScript SDKs point to by default.

If you're seeing "base URL" show up in error messages, SDK config options, or environment variables, it's almost always because something in your setup — an SDK client, an .env file, a proxy, or a self-hosted gateway — needs to know where to send HTTP requests. Getting this value wrong (typo, wrong protocol, trailing slash issues) is one of the most common causes of connection errors when integrating Claude programmatically.

Why "Base URL" Is a Configurable Setting

Most HTTP client libraries, including Anthropic's official SDKs, don't hardcode the API host. Instead they expose a baseURL (or base_url) parameter with a sensible default. This design exists for a few practical reasons:

• Testing and staging — some teams route requests through internal proxies for logging or rate limiting before they reach production.
• Enterprise networking — companies with strict egress rules sometimes need requests to pass through an internal gateway rather than hitting the public internet directly.
• Compatible APIs — some tools let you swap in an Anthropic-compatible endpoint, which is what makes this setting relevant beyond just "advanced config nobody touches."

In the vast majority of cases, developers never need to change this value. You install the SDK, set your API key, and the default base URL just works.

Setting the Base URL in Code

Here's the default behavior with the official SDKs — you typically don't set this explicitly:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic({
  apiKey: process.env.ANTHROPIC_API_KEY,
  // baseURL defaults to https://api.anthropic.com
});

If you ever needed to override it (for a proxy, for example), it looks like this:

const client = new Anthropic({
  apiKey: process.env.ANTHROPIC_API_KEY,
  baseURL: "https://your-proxy.example.com",
});

And with a raw curl request, the base URL is simply the host portion of the full endpoint:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-4-6",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello, Claude"}]
  }'

Notice the base URL alone (https://api.anthropic.com) does nothing — you always need to append a versioned path (/v1/messages, /v1/complete, etc.) and the correct headers. The base URL is necessary but not sufficient.

Common Mistakes With the Base URL

A few things trip people up when configuring this manually:

1. Trailing slashes — https://api.anthropic.com/ vs https://api.anthropic.com can behave differently depending on how the SDK concatenates paths. Most modern SDKs normalize this, but hand-rolled HTTP clients sometimes don't.
2. Missing the version path — pointing at the base URL without /v1/... will return a 404, not an auth error, which confuses people into thinking their API key is wrong.
3. Copy-pasting a proxy URL into production code — if you tested against a local proxy or a mock server during development, forgetting to reset baseURL before deploying is a classic source of "why is nothing working in prod" bugs.
4. Confusing the base URL with the API key — the base URL tells your client where to send requests; the key tells Anthropic who is sending them. Both are required, but they solve different problems.

When You'd Actually Point Elsewhere

There are legitimate reasons to send requests to something other than api.anthropic.com, and this is where a gateway like SubToAPI fits in. SubToAPI sits in front of your existing Claude access and exposes a clean HTTPS API with its own base URL: https://api.subtoapi.app/v1/.... You authenticate with an application key (sub_live_...) instead of managing raw Anthropic credentials directly in every service, and you get streaming, tool use, and usage metadata in one dashboard alongside team seats.

The request shape is intentionally close to the pattern you already know:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-4-6",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello, Claude"}]
  }'

If you're building a product on top of Claude and want per-application keys, centralized usage tracking, and seat-based team access instead of sharing one raw key across a codebase, that's a good reason to point your base URL at a gateway rather than the raw Anthropic endpoint. Start with the quickstart guide or check the messages and streaming docs to see how request and response shapes map over. Pricing details are on the pricing page, and you can sign up with a free trial to test it against your own workload.

How to Verify You're Pointing at the Right Place

If requests are failing and you suspect a base URL misconfiguration, check three things in order:

• Print or log the fully resolved URL your HTTP client is about to call — most bugs are visible immediately once you see the actual string.
• Confirm the environment variable holding your base URL isn't accidentally set to a stale value from a .env file or CI secret.
• Test the endpoint directly with curl outside your application code to isolate whether the problem is the URL, the headers, or the request body.

Questions

Is the Anthropic API base URL the same for every account or plan? Yes. https://api.anthropic.com is the standard base URL for all direct API accounts. Enterprise customers with custom infrastructure agreements may have different arrangements, but for the vast majority of developers it's a single fixed value.

Do I need to change the base URL to use streaming or tool use? No. Streaming and tool use are handled through request parameters and headers on the same base URL and versioned path — you don't switch endpoints for different features.

What happens if I get the base URL wrong? You'll typically see a connection failure, a DNS error, or a 404 rather than an authentication error, since the request never reaches a valid route. If you're getting a 401 or 403 instead, the base URL is probably correct and the issue is your API key or headers.