How to Use Claude in Your App

If you want to use Claude in your app, the short answer is: get access to the Messages API, send a request with a model name, a system prompt, and a list of messages, then handle the response — either as a single JSON payload or as a stream of tokens. That's the entire mechanical core of it. The rest of this article covers the parts that actually take time: authentication, choosing between streaming and non-streaming, adding tool use, and deciding how to manage access once more than one person on your team needs it.

Most developers get stuck not on the API call itself, but on the decisions around it: which auth model to use, how to avoid leaking a shared key across a team, how to add usage tracking without building it from scratch, and how to keep the integration maintainable as the app grows. This guide walks through both the technical integration and those practical decisions.

What you need before writing any code

To call Claude from your app you need three things:

• An API key tied to an account with access to the model you want to use.
• An HTTP client — curl for testing, fetch/axios in Node, requests in Python, or an SDK.
• A message format decision — a system prompt, conversation history, and how you'll structure multi-turn context.

That's it at the infrastructure level. The complexity comes later, once you need streaming responses in a UI, tool calls that hit your own backend, or multiple team members each needing their own key with separate usage visibility.

A minimal integration

Here's the shape of a basic request to add Claude to a backend endpoint:

const response = 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({
    model: "claude-3-5-sonnet-20241022",
    max_tokens: 1024,
    system: "You are a concise product assistant.",
    messages: [
      { role: "user", content: "Summarize this changelog in three bullets." }
    ]
  })
});

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

For most features — a chat panel, a summarizer, a form autofill assistant — this pattern is enough. The app sends context, Claude returns text, you render it.

Streaming for anything user-facing

If Claude's output shows up in a chat UI, a comment box, or any interface where users expect an immediate response, you want streaming rather than waiting for the full completion. Set "stream": true and read the response as server-sent events, appending each token or chunk to the UI as it arrives. This is what makes an integration feel responsive instead of laggy, and it's usually the single biggest UX improvement you can make to an early Claude integration.

Adding tool use when Claude needs to act, not just answer

Plain text generation covers a lot of ground, but many app features need Claude to call functions in your system — look up a record, run a calculation, query an internal API. This is done by defining tools with a JSON schema and letting Claude decide when to invoke them, then your code executes the actual function and returns the result back into the conversation. If your app needs Claude to do more than answer questions — booking something, fetching live data, updating a database — tool use is the mechanism, and it's worth designing your tool schemas early rather than bolting them on later.

The part nobody plans for: keys, teams, and usage

A single developer with one API key works fine for a prototype. It breaks down fast once:

• More than one engineer needs to call the API and you don't want everyone sharing one key.
• You need to know which feature or customer is generating the most usage.
• You want to revoke access for one person without rotating the key for everyone.
• You need the traffic to go through HTTPS with clean, application-level API keys rather than a shared secret pasted into every service.

At that point, the question stops being "how do I call Claude" and becomes "how do I run Claude access like infrastructure." This is the gap SubToAPI (https://subtoapi.app) is built for: it turns your existing Claude access into a proper HTTPS API with application keys (sub_live_...), streaming, tool use, and usage metadata, so each app or team member gets its own key without you building a key-management layer yourself.

A request looks almost identical to calling Claude directly:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-3-5-sonnet-20241022",
    "max_tokens": 1024,
    "messages": [
      { "role": "user", "content": "Draft a short release note for v2.3." }
    ]
  }'

The difference is what's behind that key: per-application scoping, streaming support (/docs/streaming), tool use (/docs/tools), and usage data per key, all managed from one dashboard instead of scattered .env files. Plans start at €9/month (Solo), with €19 and €49 per-seat tiers for teams that need more than one key holder, and every plan starts with a free trial — see /pricing.

Getting started

If you're integrating Claude for the first time, start simple: a single non-streaming request, a hardcoded system prompt, one endpoint. Get that working end to end before adding streaming or tools. Once the core loop works, layer in streaming for user-facing features, tool use for anything requiring action, and — once more than one person or one app needs access — a key-management approach that doesn't involve copying a single secret into every service you own. The /docs/quickstart guide walks through this progression with runnable examples if you want a reference implementation.

questions

Do I need Anthropic's SDK to use Claude in my app? No. The API is plain HTTPS with JSON, so any HTTP client works — curl, fetch, axios, requests. SDKs are convenient but not required for a basic integration.

What's the difference between calling Claude directly and using SubToAPI? Calling Claude directly means managing one API key yourself. SubToAPI sits on top of your Claude access and issues separate application keys, streaming, tool use, and usage metadata per key, which matters once more than one app or person needs access.

Should I use streaming for every feature? Only for user-facing output where latency is visible, like chat or live text generation. Background jobs, batch summarization, or backend processing usually don't need it and are simpler without it.