Applications and integration

If you study one domain properly, study this one. Applications and integration is a third of the exam on its own. It is also the domain the recommended Academy course (Building with the Claude API) maps to most directly — your study hours and the marks line up here better than anywhere else. And it is where the scenario questions live: given this requirement, which architecture? Which model? Which endpoint?

A map before you set off. The exam names six subdomains; this page runs longer than six sections, on purpose. Sections 01–04 follow the first four subdomains one-to-one. Section 05 covers the two configuration subdomains together — their deep dive lives on the Claude Code page. Section 06 is a short integration aside the exam likes. Everything after that — the revision tables, the traps, the quiz — is study aid, not new syllabus. And a legend for the markup: the prose explains, the "Remember for the exam" boxes carry the facts questions are built from, and the traps are the wrong answers dressed as right ones.

01From requirement to architecture

The through-line of the first subdomain is restraint. It starts with a distinction the exam quotes directly: a business requirement states what the organisation wants — answer customer questions faster, review every pull request. A functional requirement states what the system must do to deliver it. Converting the one into the other is your job.

Then choose the least complex architecture that meets the functional requirement: one model call, or a fixed chain, or an agent — in that order of escalating cost. Agents trade latency and money for task performance, which is why a response-time target or a spend ceiling is part of the requirement itself, not a detail bolted on afterwards.

Model selection runs on three questions: what capabilities does the task actually need, how fast must answers arrive, and what does the budget allow across development and production?

Here is the shape of question the exam likes. A nightly job processes millions of records. Nobody needs the results until morning, and cost is the priority. The answer is the Message Batches API — asynchronous, and half the price of synchronous calls. Streaming is the trap answer to that question: it improves perceived latency, not cost or throughput.

Then the discipline that closes the loop: a requirement is not finished until it has a testable evaluation with a pass threshold. Evals built from your real prompts and real data are how model choices get verified instead of vibes — a theme this exam keeps returning to across domains.

02Model lifecycles and API versions

Every Claude model moves through four states. Active means fully supported — the recommendation. Legacy means no longer updated, a candidate for future deprecation. Deprecated means a replacement and a retirement date have been named. Retired means gone; requests fail.

The part people miss sits between the last two: deprecated does not mean broken. The model still answers, and nothing about your calls changes yet. Only the retirement date is a real deadline — and that distinction is a favourite exam trick.

Anthropic’s commitments here are concrete: a minimum of 60 days’ notice before a publicly released model is retired, an email to affected customers, documentation of every deprecation. When a notice lands, the recommended response is measured, not dramatic. Check which keys still call the old model — the Console’s Usage page exports a CSV broken down by API key and model. Test the replacement well before the deadline. Then migrate on purpose: not in a panic on day one, and not after the errors start.

Two boundaries the exam probes. First, Anthropic’s deprecation calendar covers only Anthropic-operated platforms — the Claude API and its cloud-hosted variants. Amazon Bedrock and Google Cloud Vertex keep their own retirement schedules for the same models; a migration plan may need different dates per platform.

Second, the versioning promise: within a single API version, Anthropic does not break existing inputs and outputs — but may add optional request fields, new output values, and new variants of enum-like values — new streaming event types included. A client that throws on an event type it does not recognise is a defect waiting for the next release. Handle unknown values gracefully.

03The Messages API in depth

One fact everything else here hangs on: the Messages API is stateless. The server stores nothing between calls. Every request carries the full conversation — every turn, every image, the system prompt — and managing, trimming and persisting that history is your application’s job.

Statelessness also licenses a trick: assistant turns in the history do not have to be things Claude actually said. Synthetic assistant messages are legal, and they are how prefills and few-shot dialogue work.

A request has three essential parts: the model, a max_tokens ceiling, and the messages list of role-plus-content turns. The response hands you back more than text. Its content is an array of typed blocks — text, tool_use, thinking — and the stop_reason field tells you why generation ended.

Persistent instructions belong in the top-level system parameter — that is the role field: who Claude is being. On several current models you can also send a system-role message mid-conversation, after a user turn; it carries the same authority, but it cannot be the first message.

Prefilling is the other power move. Put an assistant message in final position and the model treats it as the beginning of its own reply, and continues from there. End a turn with "The answer is (" with max_tokens set to 1, and you will get a single token back — stopped by max_tokens, exactly as designed.

Vision arrives as image blocks inside user turns — JPEG, PNG, GIF and WebP. Multiple images per request are fine, and they are analysed together: label them ("Image 1", "Image 2") and later turns can refer to them by name. Three ways to carry the bytes:

Streaming: set stream to true and the response arrives as server-sent events in a fixed order — message_start, then for each content block a start, one or more deltas and a stop, then message_delta and message_stop.

Two things can still surprise you mid-stream. Ping events may appear anywhere. And errors may appear after a healthy HTTP 200 — an overloaded_error, normally a 529, can arrive as an in-stream event.

Two facts about tool-call deltas deserve their own rehearsal. The deltas (input_json_delta) carry fragments of a JSON string, not JSON objects; only the assembled tool_use input at the end is an object. And the SDKs require streaming for very large max_tokens values, because plain HTTP calls time out.

One cost scenario worth knowing cold. A 40,000-token reference document gets consulted every 20–30 minutes — longer than the default cache lifetime. The answer is prompt caching with the one-hour TTL option on the cache breakpoint: you pay double for the write once, then a tenth of the input rate on every read after. Two small-print items: adding a second breakpoint does not extend the five-minute default, and automatic caching does not change your TTL options.

04The REST surface

Underneath the SDKs, the Claude API is a JSON-over-HTTPS REST service, and the exam expects you to know it raw.

Raw calls require three headers every time: an authorisation header (Authorization: Bearer, or the older x-api-key for Console keys), anthropic-version pinning the API date you built against, and content-type: application/json.

A fourth — anthropic-workspace-id — only enters the picture when a multi-workspace API key is in play. The official SDKs send the standard three automatically; the workspace header is yours to pass. And log the response’s request-id header — it is the identifier support asks for when something goes wrong.

Rate limits are expressed per usage tier as requests-per-minute and tokens-per-minute, with a monthly spend cap layered on top — one reason the token-counting endpoint earns its keep before large submissions. List endpoints paginate forward with an opaque cursor; the SDKs’ auto-pagination only goes forward.

05Instruction scopes and schema design

One subdomain here is really about configuration surfaces: the CLAUDE.md files and settings files that surround Claude Code and the Agent SDK. The short version, with the full deep-dive on the Claude Code domain page: instructions you write live in a hierarchy — organisation-managed, user, project, project-local — and auto memory is a separate thing entirely: the notes Claude writes itself.

One rule settles half the questions in this area: CLAUDE.md shapes behaviour, while settings.json enforces it. A policy that must hold — blocked commands, sandboxing, allowed models — goes in managed settings, not in prose.

The other half is schema design for structured output. The API’s constrained decoding supports a subset of JSON Schema, so the SDK helpers strip the constraints they cannot enforce (minimum and maximum, string length limits), restate them in field descriptions, and set additionalProperties: false everywhere.

Your code then validates responses against the original schema — and that is where those removed constraints actually bite. The pattern to remember: every field required, additionalProperties false, ranges documented in descriptions and checked on your side.

06Sessions and resumption

One integration-flavoured fact the exam likes. In the Agent SDK, a multi-tenant app keeping one session per user conversation should persist each session ID and pass it to resume when that user comes back.

The continue option just grabs the most recent session in the current directory — the wrong semantics for tenancy. And forking is for branching one session into alternatives, not for finding your way back.

07One page to revise from

Six subdomains of prose sit above this line. Here is the same domain as two tables and a checklist — the lifecycle the exam tests word-for-word, and the tool each cost-and-latency scenario reaches for. If you reread one thing the night before, reread this.

The night-before checklist. You should be able to say each of these without looking:

• —The four lifecycle states in order, and which one is the only real deadline.
• —The notice commitment: 60 days minimum — and that 30, 90 and 180 are the planted answers.
• —Statelessness in one sentence — and what it forces you to resend, every request.
• —The three routes for image bytes, and when each one wins.
• —The five stop_reason values, and the one that means "unfinished — resend as-is".
• —The three headers on every raw call, and the fourth the SDKs will not send for you.
• —The one rule: CLAUDE.md shapes behaviour, settings.json enforces it.

One line to draw through all of it: the ideas are stable, the numbers are not. Statelessness, the lifecycle discipline, the least-complex-architecture ladder, the shapes-versus-enforcement rule — those will outlive any product change. The dated facts — the size caps, the endpoint list, which models accept a mid-conversation system message — were checked against the official documentation in September 2026, and they are the kind of detail that can change between exam editions. Re-check them against the live docs the week you sit the exam.

08The traps in this domain

• —"Deprecated means broken" — it does not. Deprecated models answer normally until the retirement date.
• —"Anthropic’s retirement date applies on Bedrock" — partner platforms run their own calendars.
• —"The API remembers our conversation" — stateless. Resend everything, every request.
• —"A 200 means the stream succeeded" — errors can arrive as in-stream events.
• —"Each tool-call delta is parseable JSON" — they are string fragments; assemble first.
• —"SDKs send every header for me" — the standard three, yes; the workspace header, no.
• —"count_tokens is a flag on the messages call" — it is a separate endpoint, with its own cap.
• —"continue will find the right user’s session" — it takes the most recent session in the directory. Persist the ID; resume with it.

09Check yourself

Six questions — one per subdomain, in the order the page covered them. Each expands to the answer and, more usefully, why the wrong options are wrong.