Study notes · 6.1% of the exam

Technical Fundamentals

Integrate Claude reliably through SDKs that wrap the REST API: authentication and environment setup, retries, timeouts, streaming, and choosing between SSE, WebSockets, and polling.

Key points

1
The official SDKs wrap the REST Messages API (POST /v1/messages). They manage auth, anthropic-version, and content-type headers, provide typed errors, and include streaming helpers and automatic retries.
2
Raw HTTP requests need the anthropic-version and content-type: application/json headers, plus the API key, sent as x-api-key or as Authorization: Bearer. The model goes in the JSON body.
3
A no-argument SDK client reads credentials from the environment (for example ANTHROPIC_API_KEY). A job that works locally but fails auth in CI usually lacks that variable, so add it through the CI secret store and never hard-code keys.
4
Configure each environment through its own config: a separate key (or workspace) per environment for spend separation, and a base URL override (for example ANTHROPIC_BASE_URL) when traffic must go through a gateway.
5
The Messages API is stateless. Each request must include the conversation history your app wants the model to see, and there is no server-side session to continue by ID.
6
429 (rate limit), 529 (overloaded), and 5xx errors are retryable with backoff. 400, 401, and 404 are not and should be fixed. The SDKs retry retryable errors automatically (2 retries by default), and 429 responses include a retry-after header.
7
Catch the SDK typed exceptions (by class or status), most specific first. Do not string-match error messages.
8
SDK defaults use a long timeout (10 minutes) and also retry timeouts, so worst-case wall-clock is about timeout times attempts. For tight user-facing budgets, set a per-request timeout and retry count that fit.
9
Use streaming for long outputs or large max_tokens. Long idle non-streaming requests risk network timeouts, and the SDKs can still collect the final message for you.
10
Streaming uses server-sent events (SSE). The HTTP 200 comes before generation, so later failures such as overloaded_error arrive as error events in the stream. Treat a stream as successful only when it ends normally.
11
Streamed tool_use input arrives as partial JSON string deltas. Accumulate them and parse when the content block stops, or use SDK helpers.
12
The API streams over SSE, not WebSockets. Relay tokens from your backend to the browser over SSE or a WebSocket, and keep the API key server-side. Use WebSockets when you need bidirectional events such as cancel.
13
Polling suits long background jobs: a worker makes the API call and the client polls your own job store. The Message Batches API suits latency-tolerant bulk work, not interactive waits.
14
Every response carries a unique request-id header (also in error bodies and exposed by the SDKs). Log it so support can find a specific call.

Read the source

Test yourself on Technical Fundamentals

Ten questions, with the answer and explanation after each one.