Messages

POST /v1/messages accepts Anthropic's request and answers in Anthropic's response shape. Construct an Anthropic SDK client with a new base URL and your key, change the model to a slug from GET /v1/models, and the rest of the integration is untouched, including the streaming event names, which is the part an Anthropic client is strictest about.

An Anthropic client

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic({
  baseURL: "https://api.routehook.ai",
  apiKey: process.env.ROUTEHOOK_API_KEY,
});

const message = await client.messages.create({
  model: "anthropic/claude-sonnet-4",
  max_tokens: 512,
  system: "Answer in one sentence.",
  messages: [{ role: "user", content: "Describe harbour fog." }],
});

console.log(message.content[0].text);

Request parameters

max_tokens is required

Unlike POST /v1/chat/completions, this route will not run without max_tokens. That is Anthropic's rule and it is kept, because a client that relies on the requirement would otherwise start issuing unbounded generations the moment it pointed here. Omitting it is 400 invalid_request, before any upstream call is made and before any credit is reserved. It is also the ceiling the pre-flight reservation is sized on, so an honest number costs you less headroom than a large round one.

The translation

The request is translated into the gateway's internal chat request, routed through exactly the same chain as POST /v1/chat/completions (the same routing, the same failover, the same reservation and settlement), and translated back on the way out. Nothing about routing or billing is different; only the shapes at either end are.

How a generation ends

The response

{
  "id": "msg_5f81c0",
  "type": "message",
  "role": "assistant",
  "model": "anthropic/claude-sonnet-4",
  "content": [{ "type": "text", "text": "Fog swallowed the cranes one by one." }],
  "stop_reason": "end_turn",
  "stop_sequence": null,
  "usage": { "input_tokens": 9, "output_tokens": 12 }
}

The key goes in x-api-key

An Anthropic SDK sends the key as x-api-key, and this route accepts it there, which is what lets a client be constructed with nothing but a new base URL. It is the same key and the same account as a bearer token; Authorization: Bearer sk_live_… works here too if you are calling by hand. Every other route on the platform reads the Authorization header only.

Streaming

stream: true emits Anthropic's framing, not OpenAI's: named events, each written as an event: line followed by its data: line. There is no [DONE] sentinel: message_stop ends the stream. The events come in one order: message_start, then content_block_start, a run of content_block_delta frames carrying text_delta, content_block_stop, then message_delta with the final stop_reason and output token count, then message_stop.

The event stream

event: message_start
data: {"type":"message_start","message":{"id":"msg_5f81c0","type":"message","role":"assistant","model":"anthropic/claude-sonnet-4","content":[],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":9,"output_tokens":0}}}

event: content_block_start
data: {"type":"content_block_start","index":0,"content_block":{"type":"text","text":""}}

event: content_block_delta
data: {"type":"content_block_delta","index":0,"delta":{"type":"text_delta","text":"Fog"}}

event: content_block_delta
data: {"type":"content_block_delta","index":0,"delta":{"type":"text_delta","text":" swallowed the cranes"}}

event: content_block_stop
data: {"type":"content_block_stop","index":0}

event: message_delta
data: {"type":"message_delta","delta":{"stop_reason":"end_turn","stop_sequence":null},"usage":{"output_tokens":12}}

event: message_stop
data: {"type":"message_stop"}

What is not supported

The compatibility is the Messages route and its translation, and nothing wider. Everything below is a real gap, not an omission from this page. Check it against your integration before you switch a base URL.

• Model ids are ours. claude-sonnet-4-20250514 is not a model here; anthropic/claude-sonnet-4 is. An id this catalogue does not know is 409 model_unavailable, which is the one line of a ported integration you will always have to change.
• Content blocks come back as text. The response translation produces text blocks, and a stream emits text_delta and nothing else. tools are accepted and forwarded to the model, but a reply that is a tool call is not re-framed as a tool_use block, if your integration depends on tool_use, use POST /v1/chat/completions, where tool calls come back in OpenAI's shape.
• Errors are the gateway's envelope. Failures answer { error: { code, message, request_id } } with the eight codes used everywhere else here, not Anthropic's { type: "error", error: { type } }. The HTTP status is right; code that branches on Anthropic's error type is not.
• No other Anthropic route exists. Token counting, the Message Batches API, the Files API and the admin endpoints have no path here and answer 404. POST /v1/messages is the whole of the surface.
• Prompt caching and extended thinking are not part of the translation. cache_control on a block and thinking blocks are not modelled; where cached input is billed differently, the saving shows up in the charge rather than in this response shape.

Failures

Related