← Blog

Claude API Billing Endpoint: What the Docs Actually Say

2026-09-27 · 5 min read · SubToAPI Team

If you've been searching the Claude API docs for a billing endpoint — something like /v1/billing or /v1/usage that returns your account spend as JSON — you've probably noticed it doesn't exist. Anthropic's API is built around the Messages endpoint for generating completions; it does not expose a dedicated billing or usage API you can call to pull cost data programmatically.

That's the direct answer: there is no public Claude API billing endpoint. Billing and usage data lives in the Anthropic Console (a web dashboard), not in the API surface. If your search intent was "how do I query my Claude spend from code," this article covers what's actually available, why the gap exists, and the practical ways teams work around it.

What the Claude API docs actually cover

Anthropic's official API reference documents a handful of endpoints:

None of these return account-level billing data. Every response does include token usage for that specific request, in the usage object:

{
  "id": "msg_01...",
  "usage": {
    "input_tokens": 512,
    "output_tokens": 128
  }
}

That's per-request usage, not account billing. To convert it into dollars you need to multiply by your model's per-token rate yourself, and to get a running total you need to sum it across every request your application makes. There's no GET /v1/billing/current call that returns "you've spent €42.17 this month."

Why Anthropic doesn't expose this in the API

This isn't an oversight — it's a common pattern among LLM providers. Billing is treated as an account-management concern, handled through a console UI with its own auth (usually session-based, not API-key-based), while the API itself is scoped narrowly to inference. Exposing granular billing data via API key would also raise access-control questions: should every API key holder be able to see the full account's spend, or just their own key's usage? Most providers punt on this by keeping billing out of the API entirely and putting it behind account-owner login.

The practical consequence: if you're building a product on top of Claude and need to show users "you've used $12 of your $50 budget," you can't just proxy a Claude billing endpoint — you have to build that tracking yourself.

How to build billing tracking without a billing endpoint

Since Anthropic doesn't give you the number, you have to compute it from what it does give you — the usage object on every response.

let totalCost = 0;
const rates = { input: 0.003 / 1000, output: 0.015 / 1000 }; // example, check current pricing

async function trackedMessage(payload) {
  const res = await fetch("https://api.anthropic.com/v1/messages", {
    method: "POST",
    headers: {
      "x-api-key": process.env.ANTHROPIC_API_KEY,
      "anthropic-version": "2023-06-01",
      "content-type": "application/json",
    },
    body: JSON.stringify(payload),
  });
  const data = await res.json();
  const cost =
    data.usage.input_tokens * rates.input +
    data.usage.output_tokens * rates.output;
  totalCost += cost;
  return data;
}

This works, but it means every service in your stack that calls Claude has to carry this logic, keep rates in sync with pricing changes, and persist totals somewhere durable (a database, not an in-memory variable). Multiply that by multiple apps, multiple team members with their own keys, and multiple environments, and it becomes real infrastructure work just to answer "what are we spending?"

Where SubToAPI fits

This is one of the gaps SubToAPI is built to close. Instead of calling Anthropic's API directly and rolling your own usage aggregation, you call SubToAPI's endpoint with an application key (sub_live_...), and usage metadata — including token counts per request — is captured centrally and shown in a dashboard alongside your team's other keys.

A request looks like this:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Summarize this contract."}]
  }'

Same shape as the Messages API you're used to — see /docs/messages for the full request/response reference — but every call is tied to an application key, so usage is attributable per key, per seat, per app, without you writing aggregation code. Streaming responses (/docs/streaming) and tool use (/docs/tools) work the same way.

It's not a billing API in the sense of a JSON endpoint returning your total spend — it's a dashboard layer on top of your Claude usage, which for most teams is actually what "billing endpoint" searches are really after: a way to see and manage cost without hand-rolling it. Plans are Solo at €9, Team at €19/seat, and Scale at €49/seat, with a free trial at /signup. Full plan details are on /pricing.

Getting started

If you're setting this up from scratch:

  1. Read the Messages API reference to understand the usage object structure per request.
  2. Decide whether you need per-key, per-app, or per-team cost attribution — this determines whether raw API keys are enough or you need an intermediary layer.
  3. If you're proxying keys to your own users or across a team, follow /docs/quickstart to set up application keys with usage tracked automatically.
  4. Persist usage data outside request logs — don't rely on the provider to keep historical billing records accessible via API, because in Claude's case it currently doesn't.

questions

Does the Claude API have a /billing or /usage endpoint? No. Anthropic's public API only documents messages, models, and related endpoints like files and batches. Account billing and usage totals are only visible in the Anthropic Console, not via a callable API.

How do I calculate Claude API costs programmatically then? Read the usage.input_tokens and usage.output_tokens fields returned with every Messages API response, multiply by the current per-token pricing for the model you used, and sum the results yourself in your own storage.

Is there any way to get centralized usage tracking without building it myself? Yes — routing requests through a layer like SubToAPI gives you per-key usage metadata in a dashboard automatically, since every call is authenticated with an application key rather than a raw provider key. See /docs/quickstart to set it up.

Turn your Claude access into an HTTPS API

SubToAPI gives you application API keys, streaming, tool use and usage insights on top of your existing Claude access — set up in minutes.

Start free  Read the quickstart →