Applications and Integration

Applications and Integration is a third of CCDV-F — about 18 of 53 items, more than the next two domains combined. A candidate who splits study time evenly across the eight domains has already lost this exam. Spend roughly a third of your preparation here, and spend it building rather than reading: one small service that calls the Messages API, streams a response, retries a failure and submits a batch will teach more than any amount of documentation skimming.

What this domain tests is implementation detail, not architecture taste. Can you name the exact shape of a request and of a response? Do you know that the system prompt is a top-level parameter and not a message role, that max_tokens is required, that a truncated answer announces itself only through stop_reason? Can you tell a 429 from a 529 and say what each should make your code do?

The idea that unlocks the domain: treat Claude as an unreliable, rate-limited, streaming network dependency like any other, then design the boundary — timeouts, retries with backoff, idempotency, config per environment, async jobs for slow work. Nearly every item here follows from that.

• Call POST /v1/messages with x-api-key, anthropic-version and a JSON content type. The body must carry model, messages and max_tokens — all three are required, and omitting the cap is an error, not an unlimited generation.
• There are exactly two message roles: user and assistant. Conversations open with a user turn and alternate. Standing instructions, persona and rules belong in the top-level system parameter — a hand-rolled system message is just ordinary conversation text.
• A turn's content is either a plain string or a list of typed blocks (text, image, document, tool_use, tool_result). Switch to blocks the moment a turn carries more than text.
• Prefill by ending messages with an assistant turn: Claude continues that text. It is the cheapest way to force a shape, such as opening a JSON object or a required first word.
• The response returns id, role, a content block array, model, stop_reason and usage with input and output token counts. Never assume the first block is text — iterate and switch on block type.
• stop_reason is your control flow. end_turn means done, max_tokens means truncated, stop_sequence means one of your stop strings fired, tool_use means run the tool and send results back in the next user turn.
• The API is stateless. It remembers nothing between calls; you resend the whole history every turn, and your app owns storage, trimming and summarization of that history.
• Stream when a human is waiting. Events arrive as message_start, then content_block_start, content_block_delta and content_block_stop per block, then message_delta carrying the final stop_reason and output usage, then message_stop.
• Batch when nobody is waiting. The Message Batches API accepts a set of requests, each tagged with your own custom_id, and processes them asynchronously within 24 hours at roughly half the token cost.
• Size and price a prompt before sending it with the token counting endpoint — it takes the same body shape, costs nothing and turns budget guesswork into a number.
• Configuration: read the key from the environment, keep a distinct key per environment, and pin an exact model ID in production rather than a moving alias.
• Prefer the official Python or TypeScript SDK over raw HTTP. You get typed error classes, automatic retries with backoff, streaming helpers, async clients, and per-request timeout and retry overrides.

• Every failure returns an error object whose type names the class: invalid_request_error, authentication_error, permission_error, not_found_error, rate_limit_error, api_error, overloaded_error. Branch on the class, not on a substring of the message.
• Retry only what is retryable: timeouts, 429 and 5xx. A 400, 401, 403 or 404 is a bug in your request — retrying just reproduces it and burns your quota.
• 429 is you, 529 is them. 429 means you exceeded your own rate limit: slow the caller, honor the retry-after signal, queue or shed load. 529 means the service is overloaded: back off and retry, or fall back to another model tier.
• Back off exponentially with jitter, cap the attempt count, and enforce an overall deadline. Un-jittered retries from many workers reconverge into exactly the spike that caused the throttle.
• Rate limits apply per model across three dimensions — requests per minute, input tokens per minute and output tokens per minute. You can be throttled on tokens while far below the request limit; read the anthropic-ratelimit-* response headers to see which budget is actually empty.
• A timeout does not tell you whether the model ran. Retrying a completed generation bills you twice and can deliver twice, so make the unit of work idempotent: derive a stable key, record the attempt before the call, store the result against the key and return the stored result on replay.
• Truncation is silent in the text. Detect stop_reason of max_tokens and treat the payload as incomplete — half a JSON object fails downstream, or worse, parses into something wrong.
• Very long non-streaming generations can exceed the connection window and fail. Stream large outputs, and set an explicit client timeout instead of inheriting a default that outlives your own request budget.
• Never hold a user-facing HTTP request open across a long generation. Accept the job, return an identifier, do the work in a queue worker, and let the client poll, subscribe or receive a webhook.
• Streams break mid-flight: an error event or a dropped socket can arrive after you have already shown tokens. Mark the message incomplete and re-request rather than presenting a truncated answer as final; if you proxy a stream to a browser, cancel upstream when the client disconnects.
• Batch results come back unordered and per-item — individual requests can succeed, error, be canceled or expire while the batch as a whole ends normally. Join on custom_id and never rely on input order.
• Config drift is a top production failure: a key from the wrong environment, an alias that moved under you, a prompt edited only in staging. Version prompts and model IDs with the code, load them identically everywhere, and never ship an API key to a browser or mobile client — proxy through your backend so you can authenticate, quota and log.

SCRIPT — the order in which you build and harden a Claude integration.

• S — Scope. Write the success criteria and the eval set first. Quality, latency and cost targets decide the model tier and the architecture, not the other way round.
• C — Contract. Fix the request and response shape: system prompt, message turns, max_tokens, expected output format, and what your code does for each stop_reason.
• R — Route. Choose the delivery mode. Synchronous for short calls, streaming when a human is waiting, batch when nobody is, a queued job when the work outlives an HTTP request.
• I — Idempotency. Decide the replay story before you write a retry. A stable key recorded before the call is what makes a timeout safe to repeat.
• P — Protect. Keys from environment config, one per environment, never in a client. Pin the exact model ID and version prompts with the code.
• T — Tolerate. Classify errors, retry only timeouts, 429 and 5xx with jittered backoff, watch the rate-limit headers, and handle truncation and mid-stream failure as normal events.

Under exam pressure, walk the letters: most application-design questions are asking which of these six steps the described system skipped.