← Blog

How to Claude API: A Practical Setup Guide

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

How to Claude API: The Short Answer

If you're asking "how to Claude API," you almost certainly want one of two things: a working request that returns a Claude response, or a clear path from zero to a production integration. Both are simpler than they look. You need three things — an API key, an HTTP client (curl, fetch, or an SDK), and a request body shaped the way Claude's Messages API expects.

The rest of this guide walks through that path step by step: getting access, authenticating, sending your first message, handling streaming responses, and using tools. It also covers where a service like SubToAPI fits in if you'd rather manage keys, billing, and team access in one dashboard instead of wiring all of that yourself.

Step 1: Get API Access

There are two common routes:

If you're building something small and solo, either works. If you're on a team and need multiple people hitting the API with individual keys, usage visibility, and per-seat billing, a layer on top of the raw API saves real setup time. That's the core reason products like this exist — the underlying model access is the same, the operational overhead around it is what differs.

Step 2: Authenticate Your Requests

Every request needs an authorization header. The exact header name depends on which provider or proxy you're using, but the shape is always the same: a bearer token or API key sent with every call.

With SubToAPI:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4",
    "max_tokens": 1024,
    "messages": [
      {"role": "user", "content": "Explain how HTTP caching works in three sentences."}
    ]
  }'

Store the key as an environment variable, never hardcode it in source, and never commit it to a repo. If you're working with a team, this is also the point where you decide whether everyone shares one key (bad for tracking usage per person) or gets their own (much easier to audit later).

Step 3: Send Your First Request

The Messages API is the core of Claude's HTTP interface. You send a list of messages with roles (user, assistant) and get back a response object containing the model's reply plus usage metadata.

A minimal request needs:

const response = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-sonnet-4",
    max_tokens: 1024,
    messages: [
      { role: "user", content: "Summarize the plot of Hamlet in two sentences." }
    ]
  })
});

const data = await response.json();
console.log(data.content[0].text);

Full request/response shapes, including system prompts and multi-turn conversations, are covered in /docs/messages. If you're just getting oriented, /docs/quickstart walks through the same flow with a runnable example.

Step 4: Handle Streaming Responses

For chat interfaces or anything where perceived latency matters, you don't want to wait for the full response before showing anything to the user. Streaming sends the response back token by token as server-sent events.

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4",
    "max_tokens": 1024,
    "stream": true,
    "messages": [{"role": "user", "content": "Write a short poem about the sea."}]
  }'

Your client needs to parse the SSE stream and append chunks as they arrive. Most frontend frameworks handle this with a simple reader loop over the response body. Details and edge cases (reconnects, partial JSON, stream termination) are in /docs/streaming.

Step 5: Add Tool Use if You Need It

If your app needs Claude to call functions — looking up data, hitting an internal API, running a calculation — tool use lets you define function schemas that Claude can invoke mid-conversation. You describe the tool's name, description, and input schema; Claude decides when to call it and returns structured arguments instead of free text.

{
  "model": "claude-sonnet-4",
  "max_tokens": 1024,
  "tools": [
    {
      "name": "get_weather",
      "description": "Get current weather for a location",
      "input_schema": {
        "type": "object",
        "properties": {
          "location": { "type": "string" }
        },
        "required": ["location"]
      }
    }
  ],
  "messages": [{ "role": "user", "content": "What's the weather in Lisbon?" }]
}

The response comes back with a tool_use block containing the function name and arguments, which your code executes and feeds back into the conversation. Full patterns for multi-step tool loops are in /docs/tools.

Step 6: Track Usage and Costs

Every response includes usage metadata — input tokens, output tokens — so you can attribute cost per request, per user, or per feature. This matters more than it seems early on: token usage compounds fast once you have real traffic, and without visibility you'll find out about a cost spike from an invoice, not from monitoring.

If you're running this across a team, per-key usage breakdowns and seat-based billing (Solo, Team, Scale plans, see /pricing) remove the need to build that tracking yourself.

Putting It Together

The technical core of "how to Claude API" is small: one endpoint, a JSON body, an auth header. The complexity that trips people up is almost always operational — key rotation, per-user billing, team access control, usage auditing. Get the request working first with a single key, then decide whether you need infrastructure around it before you scale past one developer.

Questions

Do I need a credit card to try the Claude API? Most access paths require billing details before production use, but trial access is available — signup includes a free trial period before any plan charge.

Can multiple people on my team use the same API key? It works technically, but it defeats usage tracking and makes revoking access for one person impossible without breaking it for everyone. Per-user keys under a shared account are the better pattern.

What's the difference between calling the API directly and using a proxy like SubToAPI? The requests and responses are the same shape. The difference is what's built around them — key management, streaming, tool support, and team billing in one dashboard instead of assembled from scratch.

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 →