On this page
TLDR
For standard model inference, the Messages API (POST /v1/messages) is the primary endpoint, tools, structured outputs, and streaming are request parameters on that same endpoint, not separate APIs or protocols. It is not the only endpoint Anthropic exposes: Message Batches, Token Counting, Models, Files, and Admin are separate, purpose-specific APIs alongside it. "Real-time" in the Claude API means HTTP streaming over Server-Sent Events, not a persistent WebSocket connection, an assumption worth checking before designing a chat or voice UI. Claude docs: streaming
What it is
For standard model inference, whatever language or interface it's written in, a Claude integration ultimately calls the Messages API (POST /v1/messages) - the primary inference endpoint, not the only endpoint Anthropic exposes. Tools, structured outputs, and streaming are all request parameters on that same endpoint, not separate APIs. Anthropic's official SDKs, shipped for Python, TypeScript/JavaScript, Java, Go, Ruby, C#, and PHP, are thin, code-generated clients over that REST surface: typed request/response objects, retries, and pagination, but every inference call still resolves to a plain HTTPS request to /v1/messages.
Around that primary inference endpoint, Anthropic publishes a family of separate, purpose-specific APIs: the Message Batches API (POST /v1/messages/batches) for async, high-volume processing at a cost discount; the Token Counting API (POST /v1/messages/count_tokens); the Models API (GET /v1/models) for listing available models; the Files API (POST /v1/files) for uploading content reused across calls; and an Admin API for organization-level management (workspaces, API keys, usage). "One endpoint" is a useful simplification for the inference path specifically, not a claim that the Claude API surface has exactly one endpoint overall. The distinction to internalize for CCD-F: (1) SDK versus raw REST is a convenience layer over the Messages API, not a different protocol, and (2) "real-time" in the Claude API means HTTP streaming (Server-Sent Events) on that same Messages endpoint, not a persistent WebSocket connection, an assumption worth checking before designing a chat or voice UI around it.
How it works
SDKs are wrappers, and the docs say so per language, not just in general. The TypeScript SDK page states it "provides convenient access to the Anthropic REST API from TypeScript or JavaScript." The Python SDK page states the same: "provides convenient access to the Anthropic REST API from Python applications... supports both synchronous and asynchronous operations, streaming." Anthropic also ships an ant CLI for shell scripting and typed flags, and separately, framework-compatibility layers (an OpenAI-SDK-compatible surface, an Apple Foundation Models Swift package) that expose Claude through another framework's API shape rather than the Messages API directly, distinct from the seven general-purpose client SDKs.
Streaming uses Server-Sent Events, not WebSockets. Setting "stream": true on a Messages API request incrementally streams the response using server-sent events; raw curl against a streaming request shows event: content_block_delta lines as plain HTTP chunks. SSE is one-way and HTTP-native: the client opens a normal HTTPS request and reads a chunked response, no bidirectional socket upgrade required. The SDKs' .stream() helpers (e.g. the Python and TypeScript clients) are convenience wrappers around parsing this same SSE stream, they don't open a different connection type underneath.
Tool-call arguments stream too, as partial JSON. Streamed tool-use blocks arrive as input_json_delta events containing partial JSON fragments; an application can show "thinking..." while arguments fill in, but should wait for content_block_stop before invoking the tool, to avoid executing on partial, malformed arguments.
There is no public, Anthropic-hosted WebSocket Messages API. A developer-facing WebSocket endpoint analogous to OpenAI's Realtime API does not exist in Anthropic's official docs. The only WebSocket associated with "Claude" is an internal, undocumented voice-input feature inside the Claude Code CLI client itself, a coding-agent client implementation detail reverse-engineered by third parties, not a published API surface for third-party developers to build against.
Voice and real-time apps compose services rather than using one Claude WebSocket. Anthropic's own cookbook pairs a third-party speech-to-text/text-to-speech WebSocket (ElevenLabs) with ordinary REST calls to Claude for the reasoning turn. WebSockets sit in the audio layer of that architecture, not the model layer; Claude is still called over REST/SSE in the middle of the pipeline.
Where you'll see it
Streaming chat UI
Renders tokens as they arrive using stream: true and Server-Sent Events, consumed via an SDK's .stream() helper, with no WebSocket server built or maintained.
Low-latency voice assistant
Pairs a WebSocket to a speech vendor (ElevenLabs, per Anthropic's cookbook) for audio in/out with ordinary REST/SSE calls to Claude for the reasoning turn in the middle of the pipeline.
Code examples
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-opus-4-8",
"max_tokens": 1024,
"stream": true,
"messages": [{"role": "user", "content": "Hello"}]
}'
# Response is plain HTTPS, chunked as Server-Sent Events, not a WebSocket upgrade:
# event: message_start
# data: {...}
#
# event: content_block_delta
# data: {"delta": {"type": "text_delta", "text": "Hi"}}
#
# event: message_stopSide-by-side
| Layer | Protocol | Who provides it | Use it for |
|---|---|---|---|
| Messages API (raw REST) | HTTPS POST /v1/messages | Anthropic-hosted endpoint | Any language, full control over the request |
| Official SDK (7 languages) | Same REST endpoint, typed wrapper | Anthropic client library | Idiomatic types, retries, .stream() helper |
| Streaming (`stream: true`) | Server-Sent Events over the same HTTPS connection | Part of the Messages API itself | Token-by-token UX; one-directional, HTTP-native |
| Voice/real-time pipeline | WebSocket to a 3rd-party speech vendor + REST/SSE to Claude | You compose it | Low-latency audio in/out, with Claude's reasoning turn still over REST |
Decision tree
Do you need typed request/response objects, retries, and a built-in streaming helper, rather than raw HTTP control?
POST /v1/messages directly; nothing an SDK offers is unavailable at the raw REST layer.Do you need token-by-token, low-latency text output in a UI?
stream: true and consume Server-Sent Events, either raw or via an SDK's .stream() helper; no WebSocket server is required.POST request is sufficient.Do you need bidirectional, persistent, low-latency audio (voice input/output)?
Are you assuming Anthropic hosts a public WebSocket endpoint for Claude text messaging, comparable to OpenAI's Realtime API?
Question patterns
A team building a Claude-powered chat UI plans to stand up a dedicated WebSocket server so responses can render token-by-token. Is that infrastructure necessary?
stream: true on a normal Messages API POST and consume the response as Server-Sent Events (or via an SDK's .stream() helper); token-by-token rendering doesn't require a WebSocket at all. Named distractor: "yes, WebSockets are required for any low-latency streaming UX", wrong, SSE over a standard HTTPS request already delivers that.A team building a low-latency voice assistant assumes a single WebSocket connection to Claude can carry both the audio stream and the reasoning turn. What's the correct architecture?
"use Anthropic's Realtime WebSocket API for both", no such public, developer-facing endpoint exists.A developer asks whether the official Python SDK talks to Claude over a different protocol than a raw `curl` call to the same endpoint. What's the answer?
"the SDK uses a persistent binary protocol for lower latency", no such protocol exists in the official SDKs.A developer searches Anthropic's docs for a WebSocket-based "Realtime API," similar to OpenAI's, to reduce round-trip overhead in a chat app. What should they conclude?
"reverse-engineer the Claude Code CLI's internal voice websocket for production use", that's an undocumented internal feature, not a supported integration path.During a streaming response that includes a tool call, an application wants to start showing the tool's arguments to the user as they arrive, then execute the tool once arguments are complete. What event handling is correct?
input_json_delta events to display partial JSON as it streams in, but wait for content_block_stop before actually invoking the tool, to avoid executing on incomplete or malformed partial arguments. Named distractor: "invoke the tool as soon as the first input_json_delta event arrives", that risks running the tool with a partial, invalid argument object.Frequently asked
Does the official SDK talk to Claude over a different protocol than raw REST calls?
POST /v1/messages request.Is there an official Anthropic WebSocket API for real-time voice, comparable to OpenAI's Realtime API?
Work this with your AI
Work this concept hands-on with Claude Code, Codex, or claude.ai. Copy a prompt, paste it into your assistant, and practise in tandem. Each one keeps you active (explain it back, get drilled, or build) rather than just reading.
- Drill it like the exam (scenario MCQs)Practice in the exam's scenario-MCQ format with trap awareness.
- Explain it back (Feynman)Build durable, transferable understanding of a concept you can half-state.
- Test me, adapting the difficultyActive recall practice on a concept you think you know.
- Check my prerequisites firstBefore studying a concept that keeps not sticking.
- Find the high-leverage 20%When a domain feels too big and you are short on time.