Claude API Mechanics

Claude API Mechanics carries 6.8 percent of the blueprint, about four scored questions and the third-largest sub-skill on the paper. It is the most literal material in the certification: there is a request shape, a response shape, and a set of rules about what may appear where. The questions are correspondingly precise, and a candidate who has only ever reached the model through a framework wrapper tends to find them uncomfortable, because the wrapper has been answering these questions on their behalf.

Two ideas carry most of the weight. The first is that content is a list of typed blocks rather than a string, in both directions. A message you send may combine text, images, documents and the outcomes of tool calls. A message you receive may combine text, reasoning, and requests to run tools. Code that grabs the first block and reads a text field off it is relying on something the API never promised.

The second is that the parameter surface is versioned by model. Several parameters that were correct advice one generation ago are now rejected outright, and knowing which ones is worth marks on its own.

What the exam tests here

• •Assembling a valid request: what is required, what is top-level, and what belongs inside the message list
• •Narrowing typed content blocks instead of assuming a single text block in either direction
• •The block types making up one tool round trip and how they reference one another
• •Constraining output with a response format or a strict tool schema, and the current parameter for doing it
• •Which request parameters current models reject outright, and what replaced each of them
• •The supporting endpoints (token counting, models, files, batches) and what each is actually for

The request surface

A minimal call names a model identifier, an output cap and a list of messages, and those three are the only required fields. Everything else shaping behaviour sits alongside them rather than inside the conversation.

The system prompt is a top-level field, not a message with a system role. Tool definitions are a top-level list. Reasoning configuration and effort are their own top-level structures. The message list has rules of its own worth knowing: it opens with a user turn, alternates in the ordinary case, and consecutive messages sharing a role are merged into one turn rather than rejected. Each message's content is either a plain string, which is shorthand, or the list of blocks that string expands into.

Content blocks are a tagged union in both directions

Every block carries a type, and the type tells you which other fields exist.

Outbound you may send text, images, documents and tool results together in one user turn, and ordering affects comprehension: a document or image placed before the instruction referring to it reads better than the reverse. Inbound, an assistant turn can hold text, reasoning blocks and tool requests at once, so the shape depends on what happened rather than on what you expected.

The correct pattern is to iterate the content list, branch on the type, and collect the text blocks rather than reading one. In a typed language the compiler insists on this. In an untyped one nothing does, which is why the same bug keeps reaching production.

Constraining the output

When a downstream component needs a specific shape, asking for it in the prompt is the weakest option available. Two mechanisms do better.

A response format constraint on the request itself, supplied through the output configuration, holds the whole response to a schema you provide. A strict flag on an individual tool definition guarantees the arguments the model supplies validate against that tool's schema, provided the schema is closed with additional properties disallowed and its required fields named.

Note the naming, because it is examinable: the response format lives inside the output configuration structure, and the older top-level format parameter is deprecated. Some SDKs also expose a parse helper that applies the schema and hands back typed data in one call.

The parameter surface moves between model generations

This is where stale knowledge costs marks. Fixed reasoning budgets expressed as a token allowance are rejected with a client error on the current Opus and Sonnet generations; depth is steered with an effort setting instead. Sampling controls such as temperature are likewise rejected on those models, so determinism is not something you can dial in. Prefilling an assistant turn to force a format returns an error rather than shaping the answer.

None of these were wrong advice historically, which is exactly what makes them effective distractors. The defensive habit is to treat the model identifier as part of the request contract: when it changes, re-read which parameters that model accepts rather than assuming your request still validates.

Where candidates go wrong

Common questions