CCDV-F Glossary - Applications & Integration

Quick-lookup definitions for every domain, with exam context and links back to the lesson that covers each term.

stop_reason: The response field that tells an application loop why generation ended: end_turn (natural completion), max_tokens (hit the output cap mid-generation, so the content is truncated), stop_sequence (a custom sequence you supplied was hit), tool_use (Claude wants a tool executed before continuing), pause_turn (a long-running server-side tool turn paused and should be resumed by sending the response straight back), or refusal (the model declined to continue on an otherwise normal 200 response).; Exam context: A classic distractor is code that only branches on end_turn and tool_use and silently mishandles the other four values - for example treating a max_tokens truncation as a completed answer. The exam expects you to know all six values, not just the two most common ones.; See also: 1.1 - The Messages API: Requests and Responses
API Statelessness: The Messages API has no server-side conversation object or session id - every call must resend the full message history the model needs, including prior assistant turns and any tool results, or Claude has no access to anything not included in that call's messages array. Because the client owns the entire history, it can also edit it: trimming a stale tool result or summarizing an old turn are legitimate application-level techniques.; Exam context: A common wrong answer assumes the API remembers earlier turns because a session or conversation id was used previously. The exam tests whether you know statelessness is why context management and prompt caching exist - cost and latency scale with resent history, not with how long the conversation has felt.; See also: 1.1 - The Messages API: Requests and Responses
SSE Event Lifecycle: With stream: true, a response arrives as server-sent events: one message_start, then a content_block_start / run of content_block_delta / content_block_stop cycle per content block, then a top-level message_delta (carrying the final stop_reason and cumulative output usage), then message_stop. Delta shape depends on block type - text_delta for text, input_json_delta with partial_json fragments for tool_use, thinking_delta plus a final signature_delta for thinking.; Exam context: The exam likes to trap on reading stop_reason early: it is null in message_start and only becomes final and reliable on message_delta. Also watch for a mid-stream error event (e.g. overloaded_error) after an initial 200 - a client that only checks the connection-time status code misses it, and a dropped stream is not resumable, so recovery means a fresh request.; See also: 1.2 - Streaming Responses
Structured Extraction via Forced Tool Call: The strongest pattern for pulling a value out of an image: give Claude an image content block plus a tool whose input_schema defines exactly the fields needed, and set tool_choice to force that tool. This produces a typed, directly-validatable object instead of free text needing a fragile parsing step, and asking for an extra field (like the currency symbol seen) gives a free cross-check signal.; Exam context: Vision extraction of fine-grained values (a receipt total, a small chart value) is exactly where a model can misread a digit. The exam frames unverified auto-action on a single vision pass as the core design flaw in scenarios - the fix is a verification step (schema validation, threshold check, or human review), not switching models or endpoints.; See also: 1.3 - Vision: Working with Images
Cache Breakpoint (cache_control): A cache_control field of type ephemeral placed on a content block, marking that everything before it can be reused on a later call instead of reprocessed. Up to four breakpoints are allowed per request. The win only materializes when the cached prefix is large and genuinely repeated - the breakpoint belongs after stable content (system prompt, tool definitions, a shared document) and before the part that changes every turn.; Exam context: A frequent wrong answer places the breakpoint at the very end of the request, after the unique per-call user message - that caches nothing reusable. Also tested: a cache write costs more per token than an ordinary input token, so a breakpoint on content sent only once is a net loss, not a savings.; See also: 1.4 - Prompt Caching for Cost and Latency
Exact-Prefix Cache Matching: Prompt caching only hits when everything up to and including the cache-controlled block is byte-identical to what was previously cached - a reordered tool array, one changed word in the system prompt, or a toggled feature flag on the tool list all cause a full cache miss for that segment, not a partial hit.; Exam context: The exam tests this against the intuitive but wrong idea of a 'partial' or 'fuzzy' cache hit. Also tested: caching reduces the cost/latency of reprocessing input, never the speed of generating output - an answer claiming caching speeds up generation itself is a trap.; See also: 1.4 - Prompt Caching for Cost and Latency
tool_result Block: The content block an application sends back after executing a tool Claude requested, placed inside a new user message (never appended to the assistant's own turn) and keyed to the original call via tool_use_id. A failed execution should still return a tool_result, with is_error: true and a description of what went wrong, rather than crashing the loop or omitting the result.; Exam context: Two traps recur: (1) treating a tool result as belonging on the assistant message since 'the model asked for it' - it's application-supplied, so it's a user-role turn; (2) when Claude returns multiple tool_use blocks in parallel, sending only one result or concatenating results into a single block instead of one correctly-tool_use_id-matched tool_result per call.; See also: 1.5 - Wiring Tool Use into an Application Loop
tool_choice: The request parameter controlling how much freedom Claude has to call tools: auto (default - decide whether and which), any (must call some tool, Claude picks), tool with a name (force one specific tool), or none (disable tool calling this turn even though tools are defined). Forcing a specific tool is the standard pattern for structured extraction.; Exam context: Distinguish tool_choice: none (tools stay defined but unusable this turn) from simply omitting the tools array - the exam can test whether you know tools remain declared either way, just unusable under none.; See also: 1.5 - Wiring Tool Use into an Application Loop
Thinking Block Signature: A cryptographic signature field on a thinking content block (delivered as a final signature_delta event when streaming) that the API uses to verify the thinking content wasn't tampered with when replayed on a later turn. Thinking blocks - including redacted ones (redacted_thinking, encrypted content from a safety flag) - must be passed back byte-for-byte, unmodified, in later turns; they cannot be hand-edited, summarized, or reconstructed.; Exam context: A common trap is stripping the thinking block from history 'to save tokens' before a follow-up tool-use turn - this can break the model's reasoning continuity and, since signature verification is in play, a hand-edited block can fail validation outright rather than just quietly degrading quality.; See also: 1.6 - Extended Thinking in Production Apps
Batches API: A dedicated endpoint for submitting many independent Messages API requests as one job, retrieved asynchronously once the whole batch completes, at meaningfully lower cost per request than the same volume sent as individual synchronous calls. Each item carries its own custom_id used to match results back to the original request; it trades latency (results arrive later, not instantly) for throughput and price.; Exam context: The exam's decision test is two questions: does a human need the result right now, and does any step depend on a prior step's output? High-volume, independent, no-real-time-deadline work (e.g. overnight ticket classification) is the Batches API's sweet spot; reaching for an agentic loop for the same task is a tested over-engineering trap.; See also: 1.7 - Claude Application Design Patterns
Exponential Backoff with Jitter: The correct retry strategy for a 429 (rate limited) or 5xx/overloaded_error (transient server-side failure): each retry waits roughly double the previous delay, capped at a maximum, plus a small random jitter offset. Jitter specifically prevents many clients throttled at the same moment from retrying in lockstep and re-triggering the same limit together (a thundering herd).; Exam context: The exam distinguishes retryable failures (429, 5xx) from permanent ones (400, 401, 403) - retrying a malformed request (400) forever is a classic wrong answer, since the identical broken payload produces the identical error every time.; See also: 1.8 - Rate Limits, Retries and Idempotency
Idempotency Key: A key supplied on a request so that a retried call with the same key is recognized as a duplicate rather than re-executed. It protects against the case where a request actually succeeded server-side but the client never received the response (a dropped connection or timeout) - a naive retry in that scenario would duplicate any side effect the call triggered.; Exam context: Tested as the fix specifically for retries on calls with side effects (a tool execution, a billing-tied request) - reuse the same key across every retry attempt of one logical operation; generating a new key per retry defeats the purpose.; See also: 1.8 - Rate Limits, Retries and Idempotency
Backend Proxy Pattern: The required architecture for any client-facing (browser or mobile) app: the client calls your own backend, which holds the real API key server-side and forwards the request. This is the only architecture where the credential actually stays secret, and it gives you a place to enforce per-user rate limits and rotate the key without shipping a new client build.; Exam context: The exam frames calling the Messages API directly from client code with an embedded key as extractable and effectively public - the flaw is the exposed credential itself, not a networking or header-format limitation (both common wrong-answer red herrings).; See also: 1.9 - API Keys, Auth and Config Management
Structural Assertion: A test assertion on Claude output that checks a durable property - valid JSON matching a schema, a required field present and correctly typed, a classification landing in an allowed set - rather than exact wording. It survives the model rephrasing an answer while still catching a genuine regression like a missing field or invalid category.; Exam context: Asserting exact string equality on live, non-deterministic model output in a CI test is a textbook trap: it's flaky by construction and breaks on any harmless phrasing change. Deterministic code (request construction, response parsing) should instead be unit-tested with mocked responses.; See also: 1.10 - Testing Claude-Integrated Applications
Pinned Model Version vs. Alias: A dated, immutable model version string always refers to exactly the same model behavior; a rolling 'latest' alias shifts to a newer underlying model over time with no code change on your part. Aliases suit local development and prototyping; a live production feature should pin a specific tested version and upgrade deliberately, validating against an eval set before rollout, since output format habits and edge-case handling can shift between versions even when overall quality improves.; Exam context: The exam treats 'newer is presumably better, no need to test' as a trap - aggregate benchmark improvement doesn't guarantee no regression on a specific feature's format requirements. Also tested: pinned versions are eventually deprecated on a published timeline, so pinning trades silent drift for the responsibility to track deprecation notices and migrate proactively.; See also: 1.11 - Versioning and Rolling Out Model Changes