Applications and Integration

33.1% of the Claude Certified Developer – Foundations blueprint — roughly 18 of the 53 questions on a real sitting.

Applications and Integration is 33.1% of the CCDV-F blueprint — roughly 18 of the 53 scored questions, and by a wide margin the largest domain. Nothing else comes close: the next-biggest is Model Selection and Optimization at 16.8%. If you only have time to prepare one domain properly, prepare this one.

It is also the broadest. The blueprint decomposes it into six sub-skills, and the two largest are not the ones candidates expect. Claude Application Design is 8.6% and Software Engineering Foundations is 7.4% — together more than a fifth of the whole exam — while Claude API Mechanics is 6.8%, Configuration Management 4.1%, Understanding Requirements 3.4% and Systems Life Cycle 2.8%. The consequence is that most of this domain is ordinary senior-engineering judgement applied to a system that happens to call a model: idempotency, retries, statelessness, failure isolation, secrets handling, environment separation, versioning and rollout.

That framing matters because it changes what a wrong answer looks like. The distractors here are rarely exotic. They are the shortcuts a competent engineer takes when they forget the model is a remote, non-deterministic, rate-limited dependency: retrying a 400, holding conversation state on the server and assuming the API does too, treating a model response as trusted input, or putting a credential somewhere it will be persisted. Read every scenario as an integration problem first and a Claude problem second, and the correct option is usually the one that treats the model call like any other unreliable network dependency — with a contract, a timeout, a retry policy and a fallback.

What the exam actually tests

  • —The Messages API is stateless — conversation state, and its cost, belong to the caller
  • —Branching on `stop_reason` rather than reading `content[0]` unconditionally
  • —Which HTTP failures are retryable (429, 5xx, connection errors) and which are not (400, 401, 403, 404)
  • —Choosing between synchronous, streaming and the Batch API for a given workload
  • —Where configuration and secrets live — environment and secret store, never prompt text or message history
  • —Treating model output as untrusted input at every boundary that consumes it

The Messages API is stateless

There is no server-side conversation, thread or session on `POST /v1/messages`. Every request carries the entire history you want the model to see, and every request is billed for that history. Multi-turn behaviour is something your application implements: you append the assistant's returned content to your message list, append the next user turn, and send the whole array again. Two consequences show up constantly on the exam. First, cost and latency grow with conversation length, which is why prompt caching and context management exist. Second, anything you want remembered across process restarts must be persisted by you. A request body needs `model`, `max_tokens` and `messages`; the system prompt is a top-level `system` parameter, not a message with a system role, and the first message must be a user turn.

stop_reason is the branch point

Every response carries a `stop_reason`, and production code branches on it before touching content. `end_turn` means the model finished normally. `tool_use` means it wants a tool executed and the loop must continue. `max_tokens` means output was truncated by your own cap — the answer is incomplete, not wrong. `stop_sequence` means a configured sequence was hit. `pause_turn` means a server-side tool loop paused and the request should be resumed by sending the assistant turn back. `refusal` means safety classifiers declined; content may be empty or partial, and `stop_details` carries the category. Code that does `response.content[0].text` without checking `stop_reason` is the single most common defect in this domain, because it crashes exactly when the system is under stress.

Retry policy: retry the retryable, fail fast on the rest

The API returns a typed error envelope with a status, an `error.type` string and a `request_id`. 429 `rate_limit_error`, 500 `api_error`, 529 `overloaded_error` and connection failures are transient: retry with exponential backoff, and honour the `retry-after` header when the response supplies one. 400 `invalid_request_error`, 401 `authentication_error`, 403 `permission_error`, 404 `not_found_error` and 413 `request_too_large` are not: retrying them burns quota and delays the real fix. The official SDKs already retry the transient set with backoff, defaulting to two retries, and expose typed exception classes — branch on those rather than string-matching an error message. Include `request_id` in your logs; it is what makes a support conversation tractable.

Choosing the call shape: synchronous, streaming, or batch

Three delivery modes, three different problems. A plain synchronous call fits short, interactive, latency-sensitive work. Streaming fits anything a user watches — and becomes effectively mandatory for large generations, because a non-streaming request with a very large `max_tokens` can exceed the SDK's HTTP timeout. The Batch API (`POST /v1/messages/batches`) fits bulk, non-interactive work: it bills at 50% of standard rates, accepts very large request sets, and completes asynchronously — most batches within an hour, with a 24-hour ceiling. The batch detail examiners love is that submission order is not a guarantee: each request carries a `custom_id` (1–64 characters, alphanumerics, hyphens and underscores), and you key results by that ID rather than by position.

Configuration management and environment separation

Model IDs, effort levels, prompt versions, tool sets, timeouts and feature flags are configuration, not literals scattered through the call sites. Pulling them into config is what makes a model swap or a prompt rollback a deploy rather than a rewrite, and it is what lets staging and production differ safely. Credentials are a stricter case: an API key belongs in an environment variable or a secret manager, is read by the harness, and never appears in a system prompt, a user message or a tool description. Prompts and messages are persisted in conversation history and logs, so a secret placed there is durably readable long after the request. Pin model IDs deliberately — a floating alias is convenient in development and a surprise in production.

Where candidates go wrong

Trap 1 — 'The API keeps the conversation for me'

Candidates coming from assistant-style SDKs look for a session or thread identifier on the Messages API and pick the option that implies one exists. It does not. Multi-turn is entirely client-side: you resend the full history every call. This trap has a second half — because history is resent, a long conversation gets more expensive every turn, and the fix is prompt caching or context management, not a server-side memory the API does not offer.

Trap 2 — 'Wrap the call in a retry with exponential backoff'

Presented as a robustness improvement, this is only half right. Backoff is correct for 429s, 5xx responses and connection errors. Applied blindly it also retries 400s and 401s — a malformed request or a bad key will fail identically every time, so the retry loop just multiplies the failure and consumes rate-limit headroom. The exam-correct answer distinguishes retryable from non-retryable status classes, and usually also honours `retry-after` rather than inventing its own delay.

Trap 3 — 'Put the credential in the prompt so the model can use it'

A scenario has the model calling an authenticated third-party service, and one option supplies the key in the system prompt or a user message 'so Claude has it'. This is wrong twice over: the model does not make network calls, your harness does, and prompt and message content is persisted in conversation history where the secret remains readable. The correct pattern keeps the credential in the harness or a managed credential store and has the model request an action through a tool, with the authenticated call executed on your side.

Trap 4 — 'Model output is structured, so parse it directly'

Two failures hide behind this. The first is validation: unless you constrain the response with `output_config.format` or a strict tool schema, a JSON-shaped answer is a strong convention, not a guarantee — parse defensively and handle the failure path. The second is trust: model output is untrusted input. Text that reaches a shell, a SQL string, a template or a downstream tool must be validated and escaped exactly as user input would be, because a document the model read may have contained instructions aimed at your system rather than at the user.

How to study this domain

This domain is a third of the exam, so give it a third of your time — most of it on Claude Application Design and Software Engineering Foundations, the two largest sub-skills at 8.6% and 7.4%.

The most efficient single exercise is to build a small production-shaped client from scratch, without a framework: send a multi-turn conversation, branch on every `stop_reason` value, catch typed SDK exceptions and classify them into retryable and terminal, log the `request_id`, and read the model ID from configuration rather than a literal. That teaches more of this domain than any amount of reading, because it forces every mechanic into your hands.

Then run one batch job end to end with results you can tell apart, so you see for yourself that `custom_id` is load-bearing. Finally, rehearse the boundary questions: for each of secrets, model IDs, prompts and tool definitions, say in one sentence where it lives, who can change it, and what breaks if it changes. Distractors here almost always misplace one of those four.

Common questions

How many CCDV-F questions come from Applications and Integration?

It is 33.1% of the blueprint — roughly 18 of the 53 scored questions, and the largest domain by a wide margin. Its six sub-skills are Claude Application Design (8.6%), Software Engineering Foundations (7.4%), Claude API Mechanics (6.8%), Configuration Management (4.1%), Understanding Requirements (3.4%) and Systems Life Cycle (2.8%).

How much of this domain is Claude-specific?

Less than the name suggests. Claude API Mechanics is 6.8%; the rest rewards ordinary senior-engineering judgement — requirements, lifecycle, failure handling, configuration and design — applied to a system with a remote, non-deterministic, rate-limited dependency. Read scenarios as integration problems first.

Which stop_reason values do I actually need to know?

`end_turn`, `tool_use`, `max_tokens` and `stop_sequence` are the everyday set. `pause_turn` matters once server-side tools are involved, and `refusal` matters for safety handling — it returns a successful HTTP response whose content may be empty or partial, so check `stop_reason` before reading content.

When should I use the Batch API instead of ordinary calls?

When the work is bulk and nobody is waiting on it — evaluation runs, backfills, large classification or extraction jobs. It bills at 50% of standard rates and completes asynchronously, typically within an hour and at most within 24. Do not use it for anything interactive, and key results by `custom_id` rather than by position — submission order is not a guarantee.

Do I need to memorise HTTP status codes?

You need the classification, not a table. Know that 429 and 5xx responses plus connection errors are transient and should be retried with backoff, and that 400, 401, 403, 404 and 413 are caller errors that will fail the same way on every attempt. Knowing the matching `error.type` strings helps, but the retryable-versus-terminal split is what questions turn on.

Practise this domain

The CCDV-F bank is weighted to the blueprint above, so 33.1% of what you practise is this domain — and every option carries a written explanation, not just the correct one.

See CCDV-F

Other CCDV-F domains

Not affiliated with or endorsed by Anthropic. Domain names and weightings are taken from the published exam guide; always check the official guide before booking.