22 Applications & API Integration Practice Questions & Answers

1. 1. An application keeps a multi-turn chat with Claude. When it sends the fourth user turn to the Messages API, what must the request body contain?

   • A.A short summary of the earlier turns; full history is accepted only on the first request of a conversation
   • B.Only the newest user message, because the service stores the earlier turns under a conversation ID
   • C.The newest user message plus the ID of the previous response, which the service expands server-side
   • D.The complete ordered conversation history — every previous user and assistant turn — followed by the new user message✓ Answer

   The Messages API is stateless: it keeps no server-side record of a conversation between calls, so the model can only see what the current request carries. The client owns the transcript and must resend the full ordered messages array — including the assistant's own previous replies — on every turn.

   Source: Anthropic docs — Messages API overview (stateless requests)Report a problem with this question

2. 2. A developer builds a messages array whose first entry has the role assistant, followed by a user entry. What is the documented result?

   • A.The API silently reorders the array so the user entry comes first
   • B.The request is rejected as an invalid request, because the first entry in messages must have the role user✓ Answer
   • C.The assistant entry is treated as the system prompt
   • D.The request succeeds and the assistant entry is used as a style example

   A conversation always opens with a user turn, so an assistant-first messages array is a malformed request and is rejected with a client-side (4xx) invalid-request error rather than being repaired. Assistant entries are legal later in the array — for example as few-shot examples — just not in first position.

   Source: Anthropic docs — Messages API, message rolesReport a problem with this question

3. 3. A client appends two consecutive user-role entries to messages before calling the API. How does the API treat them?

   • A.Only the last of the two is sent to the model and the earlier one is discarded
   • B.The request is rejected because an assistant entry must be inserted between them
   • C.They are combined into a single user turn✓ Answer
   • D.Each one triggers a separate assistant response in the same request

   Consecutive entries with the same role are merged into one turn, so nothing is dropped and no error is raised. This matters when code appends context (for example a retrieved document) as its own user entry just before the real question — the two arrive as one turn, in order.

   Source: Anthropic docs — working with Messages (consecutive same-role messages)Report a problem with this question

4. 4. Where should instructions that define the assistant's role and must govern the whole conversation be placed?

   • A.In a dedicated content block type that may appear anywhere inside an assistant turn
   • B.In the top-level system parameter of the request, which sits outside the messages array✓ Answer
   • C.Prepended to the text of every user message so the model sees it each turn
   • D.As the first entry of the messages array with the role system, which must always be messages[0]

   System instructions are a top-level request parameter, structurally separate from the conversation turns, which is what lets them apply to the whole exchange without being confused with user input. Stuffing them into user turns works less reliably and mixes operator instructions with untrusted user text.

   Source: Anthropic docs — Messages API, system promptsReport a problem with this question

5. 5. Which statement best describes the content field of a message in the Messages API?

   • A.It is a key/value map whose keys name the modality of each part
   • B.It must always be a plain string; non-text input requires a different endpoint
   • C.It is either a plain string or an ordered list of typed blocks such as text, image, document or tool-related blocks✓ Answer
   • D.It is a plain string for user turns and always a list of blocks for assistant turns

   Content is a list of typed blocks, with the plain string form offered only as shorthand for a single text block. The typed-block design is what lets one turn mix text with images, documents, tool calls and tool results while keeping their order explicit.

   Source: Anthropic docs — Messages API, content blocksReport a problem with this question

6. 6. Why is reading a response by taking the text of the first element of content a fragile pattern?

   • A.Because the first element is always reserved for response metadata
   • B.Because a response may contain several blocks of different types, and the text you want is not guaranteed to be first✓ Answer
   • C.Because content is returned in reverse order, so the final answer is always last
   • D.Because content is only populated when streaming is disabled

   A single response is an array that can hold several blocks of mixed types — for example a tool-use block, or cited and uncited text split across blocks — so position zero is not reliably the answer text. Robust code iterates the array and dispatches on each block's declared type.

   Source: Anthropic docs — Messages API response formatReport a problem with this question

7. 7. An application must send a locally stored screenshot to Claude for description. How is the image supplied?

   • A.As a text block containing the absolute file path, which the API reads from the caller's filesystem
   • B.As an image content block whose source carries the base64-encoded bytes together with an explicit media type identifying the image format✓ Answer
   • C.As raw binary appended after the JSON body, using a multipart request
   • D.As a text block containing the base64 string, since the model detects the format automatically

   Local images travel inside the JSON body as an image block whose base64 source declares the media type explicitly; the API does not sniff the format and has no access to the caller's filesystem. A publicly reachable image can instead be given as a URL source, and an already-uploaded file as a file reference.

   Source: Anthropic docs — vision (image content blocks)Report a problem with this question

8. 8. A user turn contains one image block and one text block asking a question about that image. What is the documented best practice for their order?

   • A.Split them into two separate user turns, image first, then text
   • B.Place the text block before the image block
   • C.Order is enforced by the API, which always moves images last
   • D.Place the image block before the text block✓ Answer

   Blocks are processed in the order given, and putting the image first means the question is read with the visual evidence already in context, which measurably improves results. The API does not reorder blocks, so the ordering is entirely the caller's responsibility.

   Source: Anthropic docs — vision, prompt structure best practicesReport a problem with this question

9. 9. A PDF contract must be analyzed in a single Messages API request. How is it supplied?

   • A.As a chain of image content blocks that the caller must render, one per page, before sending
   • B.Through a dedicated document endpoint that returns a handle for use in a later message
   • C.As a document content block whose source carries the PDF — base64 data with its media type, a URL, or a reference to a previously uploaded file✓ Answer
   • D.As a text content block containing text the caller extracted, which is the only supported form

   PDFs ride in the same messages array as everything else, as a document block, and the source can be inline base64, a URL, or a file reference — no separate endpoint or manual page rendering is needed. Because each page is handled both visually and as text, layout-heavy documents such as contracts stay interpretable.

   Source: Anthropic docs — PDF support (document content blocks)Report a problem with this question

10. 10. An agent loop sends the same large reference image on every one of its many turns, and request payloads have become huge. Which change addresses the cause?

    • A.Send the image only on the first turn and rely on the API to remember it for the rest of the conversation
    • B.Upload the image once through the files endpoint and reference the returned identifier in each subsequent request✓ Answer
    • C.Compress the base64 string with gzip inside the JSON field before sending it
    • D.Move the image into the system parameter, which is excluded from the request body size

    Because the API is stateless, inline base64 content is re-uploaded on every turn; uploading once and referencing the returned file identifier keeps each subsequent payload small. The upload-once, reference-many pattern is exactly what the files endpoint exists for, and the identifier can be reused across many requests.

    Source: Anthropic docs — Files APIReport a problem with this question

11. 11. After uploading a PNG and a PDF and receiving an identifier for each, how are they referenced in a later Messages request?

    • A.Both as image blocks, since the identifier already encodes the media type
    • B.Both as document blocks, since every uploaded file is treated as a document
    • C.The PNG as an image block and the PDF as a document block — the content-block type must match the file's media type✓ Answer
    • D.As plain text blocks containing the identifier strings, which the API replaces with the file contents

    A file identifier does not change how content is typed: the block type must match the file's media type, so images go in image blocks and PDFs or plain text go in document blocks. A mismatched block type is rejected as an invalid request rather than silently coerced.

    Source: Anthropic docs — Files API, referencing files in MessagesReport a problem with this question

12. 12. A product must show which passage of a supplied document supports each claim in Claude's answer. What is the correct mechanism?

    • A.Ask in the prompt for quotes with page numbers, which is the only supported way to get source references
    • B.Enable citations on the document content block; the response is then split into text blocks where the cited ones carry references back into the source✓ Answer
    • C.Call a separate citations endpoint afterwards, passing the response identifier
    • D.Citations are produced automatically for every document, so no request-side change is needed

    Citations are an opt-in setting on each document block, and enabling them changes the response shape: the answer arrives as multiple text blocks, with cited blocks carrying structured references that locate the supporting span in the source. That structure is what lets a UI highlight evidence reliably instead of trusting free-text quotes the model may paraphrase.

    Source: Anthropic docs — citationsReport a problem with this question

13. 13. A nightly job classifies tens of thousands of documents. No result is needed until the next morning, and cost per document matters. Which approach fits best?

    • A.Fan the documents out as parallel synchronous requests to finish as fast as the rate limits allow
    • B.Submit the work as an asynchronous batch job, which is designed for high-volume, latency-tolerant workloads and is billed at a discount✓ Answer
    • C.Keep synchronous requests but switch to the cheapest available model without evaluating quality
    • D.Keep synchronous requests but sharply lower the output token limit on each one to cut cost

    The decision rule is whether low latency is actually required; when it is not and volume is high, the asynchronous batch endpoint is the intended path because it trades turnaround time for a lower price. The three distractors each keep the real-time path and try to buy savings elsewhere: parallel fan-out only burns rate limits, cutting the output limit truncates answers, and downgrading the model without evaluation trades away accuracy blindly.

    Source: Anthropic docs — Message Batches API overview (batch vs realtime)Report a problem with this question

14. 14. What is the correct lifecycle for running work through the asynchronous batch endpoint?

    • A.Submit the batch and read the results immediately from the creation response, which blocks until they are ready
    • B.Submit the batch, poll its processing status until it reports that processing has ended, then read the results✓ Answer
    • C.Submit each request separately and poll each one by its own identifier until it completes
    • D.Submit the batch and wait for the service to open a connection back to the client with the results

    Batch processing is asynchronous by design: creation returns immediately with a batch identifier and a processing status, so the client polls that status and only fetches results once processing has ended. Nothing blocks and the service does not call back into the client, which is why the endpoint suits jobs that may run far longer than any HTTP request should.

    Source: Anthropic docs — Message Batches API, polling for completionReport a problem with this question

15. 15. A completed batch is read back. How should each result be matched to the input request that produced it?

    • A.By comparing each result's text against the original prompts to find the closest match
    • B.By the caller-chosen identifier attached to each request, because results may be returned in any order✓ Answer
    • C.By the order in which requests finished, which the service reports separately
    • D.By position, since results are returned in the same order the requests were submitted

    Each entry in a batch carries a caller-chosen identifier precisely so results can be re-associated, and the results stream carries that identifier back on every entry. Ordering is not guaranteed, so code that zips results against the input list by index will silently attach answers to the wrong records.

    Source: Anthropic docs — Message Batches API, retrieving resultsReport a problem with this question

16. 16. Why is streaming recommended for requests that are expected to produce a very long response?

    • A.Because streaming raises the maximum number of output tokens the model is allowed to produce
    • B.Because non-streaming requests are rejected outright whenever the response would be long
    • C.Because a non-streaming request keeps the connection idle until the whole response is ready, which risks a client or proxy HTTP timeout✓ Answer
    • D.Because streamed output tokens are billed at a lower rate than non-streamed ones

    With streaming off, the server sends nothing until generation finishes, so a long generation can outlast the timeout of the HTTP client or an intermediary and the request fails after the work was already done. Streaming emits events continuously, keeping the connection active and letting the client render partial output as it arrives.

    Source: Anthropic docs — streaming MessagesReport a problem with this question

17. 17. For a streamed response containing a single text block, which sequence of events matches the documented structure?

    • A.Repeated message start and message stop pairs, one for each chunk of text
    • B.Content block start, then message start, then the deltas, then message stop
    • C.Message start, then content block start, then the incremental content deltas, then content block stop, then a message-level delta, then message stop✓ Answer
    • D.A single message start carrying the finished content, followed by message stop

    The stream opens with a message-start event whose message shell has empty content, then wraps each content block in a start event, one or more incremental deltas, and a stop event, before message-level updates and a final message-stop close the stream. Handling events by this envelope structure, rather than assuming text arrives bare, is what makes a consumer work for multi-block and tool-using responses too.

    Source: Anthropic docs — streaming, event flowReport a problem with this question

18. 18. A client streams a response and needs to know why generation stopped. Where does that information arrive?

    • A.In the message-level delta near the end of the stream, which carries top-level updates such as the stop reason✓ Answer
    • B.In every content block stop event, one per block
    • C.Only by making a second, non-streaming request for the same prompt
    • D.In the message-start event, which already reports how the message will end

    The opening message-start event carries a message shell with empty content and no final stop reason, because generation has not happened yet; the stop reason is a top-level field that can only be known at the end, so it is delivered in the message-level delta. Treating it as available up front leads to code that never learns the response was, for example, cut short at the output limit.

    Source: Anthropic docs — streaming, message_delta eventReport a problem with this question

19. 19. Which mapping of an HTTP status code returned by the API to its cause is correct?

    • A.429 — the caller's key lacks permission for the requested resource
    • B.401 — the credentials are missing or invalid✓ Answer
    • C.404 — the JSON body of the request was malformed
    • D.413 — the service is temporarily overloaded

    401 signals an authentication problem — a missing, malformed, or revoked credential — and is distinct from 403, which means the credential is valid but not permitted for that resource. The other options swap well-known codes: a malformed body is 400, exceeding a rate limit is 429, an oversized request is 413, and overload is reported by a server-side 5xx status.

    Source: Anthropic docs — API errors (HTTP status codes)Report a problem with this question

20. 20. Which failures should a client retry with backoff rather than treat as permanent?

    • A.Oversized-request responses, which succeed once the service has free capacity
    • B.Rate-limit responses and server-side errors, including the overloaded status✓ Answer
    • C.Authentication and permission failures, which usually clear on their own after a moment
    • D.Malformed-request and not-found responses, since the endpoint may appear later

    Retrying only helps when the failure is transient — the request itself is valid and a later attempt can succeed — which is true of rate limiting, transient server errors, and overload. Bad credentials, missing permissions, malformed bodies, unknown resources, and oversized payloads all describe something wrong with the request, so identical retries will keep failing and only add load.

    Source: Anthropic docs — API errors, retryable errorsReport a problem with this question

21. 21. A request is rejected for exceeding the rate limit and the response carries a retry-after header. What is the correct client behavior?

    • A.Retry immediately in a tight loop until one attempt is accepted
    • B.Treat it as a permanent failure and drop the request, since rate limits do not reset
    • C.Ignore retry-after and retry on a fixed short interval, since the header is only advisory for browsers
    • D.Wait at least as long as retry-after indicates, then retry with exponential backoff and jitter, capping the number of attempts✓ Answer

    Rate limits replenish over time, so the request is retryable — but only after the interval the server itself named in retry-after, with exponentially growing waits and jitter so that many clients recovering at once do not synchronize into another spike. Immediate tight-loop retries deepen the throttling instead of clearing it, and a bounded attempt count keeps a persistent failure from looping forever.

    Source: Anthropic docs — API errors and rate limits (retry-after)Report a problem with this question

22. 22. How should an integration distinguish between the different error conditions the SDK can raise?

    • A.Catch the SDK's typed exception classes in order from most specific to least specific, ending with the base class✓ Answer
    • B.Let all exceptions propagate and rely on the SDK to retry every failure automatically
    • C.Parse the printed representation of the exception to recover the status code
    • D.Catch one broad base exception and inspect the error message text for substrings such as rate limit or not found

    The SDK defines a distinct exception class per error condition precisely so callers can branch on type, and ordering the handlers from most specific to least specific ensures a narrow case is not swallowed by the base class. Matching on message text is brittle because wording is not part of the API contract and can change without notice, and a single catch-all discards the retryable-versus-permanent distinction the classes encode.

    Source: Anthropic docs — SDK error handling (typed exceptions)Report a problem with this question

Practice questions based on the official Claude Certified Developer – Foundations (CCDV-F) exam guide and Anthropic's public documentation. This is an independent study tool, not affiliated with or endorsed by Anthropic, and does not grant certification. The real exam is 53 questions, 120 minutes, passing at a scaled 720/1000, delivered via Pearson VUE ($125). Official certification page →