Accessing the API

Your chat UI fires a request. A few hundred milliseconds later, tokens start streaming back onto the screen. In between those two moments, a specific sequence of things happens — and when something goes wrong in production, knowing that sequence is the difference between fixing the bug in ten minutes and staring at logs for an hour.

The five-step request lifecycle

Every call to Claude moves through the same shape:

1. Client to your server. The browser, mobile app, or other frontend sends a request to a backend you own.
2. Your server to the Anthropic API. Your backend attaches the API key and forwards the request to Anthropic.
3. Model processing. Claude tokenises, embeds, contextualises, and generates a response.
4. Anthropic API to your server. The response comes back with the generated text plus metadata.
5. Your server to the client. Your backend does whatever post-processing it needs, then returns the result to the frontend.

The one non-negotiable part of this flow is the server in the middle.

Why the API key lives on the server

Never put your Anthropic API key in client-side code. Not in a React component, not in a mobile binary, not in a "just for testing" HTML file. The moment that key ships to a user's device, it is leaked.

The rationale is mechanical:

• API calls to Anthropic are authenticated with a secret key.
• Anyone who can inspect your shipped code can extract that key.
• An extracted key is an open spending account on your Anthropic organisation until you rotate it.

So your architecture is always: client → your server → Anthropic. Your server owns the key, talks to the API, and returns only the response to the client. This is the same pattern you already use for any third-party API with a secret credential — Claude is not a special case.

From your server you can either call Anthropic over plain HTTP or use an official SDK. Anthropic ships SDKs for Python, TypeScript/JavaScript, Go, and Ruby. Every request you send — SDK or raw HTTP — must include at minimum:

• API key — your authentication credential
• model — which Claude model to run, e.g. claude-sonnet-4-0
• messages — the conversation history
• max_tokens — the upper bound on generated output

Inside Claude's processing

Once the Anthropic API receives your request, the model runs through four stages. You don't need to reimplement any of these — but understanding them sharpens the mental model you'll use later when debugging prompts and tuning behaviour.

Tokenisation. Claude breaks the input into tokens — chunks that are often whole words, but frequently sub-word fragments, punctuation, or whitespace. Roughly "one word = one token" is a useful first approximation and a lie in enough edge cases that you'll sometimes want to measure instead of guess.

Embedding. Each token becomes a high-dimensional vector — think of it as a numerical definition that encodes every meaning the token might carry before context narrows it down.

Contextualisation. The model refines each token's embedding using the surrounding tokens. "Bank" next to "river" and "bank" next to "deposit" come out as very different vectors by the time the model is done with them.

Generation. From the contextualised representation, the model computes a probability distribution over possible next tokens and samples one. It doesn't always pick the top choice — controlled randomness is what makes outputs fluent instead of robotic. It then repeats the whole process for the next token, and the next, and the next.

When Claude stops generating

Generation is a loop, and loops need a termination condition. Claude checks three after every token:

• Max tokens reached. You asked for at most max_tokens in the response. Once it hits that ceiling, it stops — whether or not it was "done."
• End-of-sequence token. The model generated a special token meaning "I'm finished." This is the clean, natural termination.
• Stop sequence. You provided one or more strings in the request that, if generated, should halt output. Useful for structured formats where you know exactly what the closing marker looks like.

Every response carries a stop_reason field that tells you which of these fired. In production you'll check it routinely — a max_tokens stop means your response was truncated, and that's often a bug.

The response object

When generation completes, the API returns a structured object containing:

• content — the generated text (and other block types you'll meet later when we cover tool use).
• usage — the count of input and output tokens, which is what you'll use for billing, rate-limit, and cost observability.
• stop_reason — why the model stopped, as above.

Knowing these three fields exist is enough for this lesson. In the next one you'll set up your API key and start making real calls.