Skip to main content
POST
Não misture as duas APIs: /v1/* é a API de inferência (este documento — retransmissão do upstream sem envelope); /api/* é a API de gestão (saldo/logs, etc., resposta {success, message, data}). Se vir em algum lugar que /v1/messages devolve {code, data}, este documento prevalece.

Autorizações

A autenticação suporta dois métodos, escolha um:
string
Cabeçalho de autenticação no estilo AnthropicAcesse a página de gerenciamento de chaves de API para obter sua chave de API
string
Autenticação Bearer Token (alternativa a x-api-key)
string
Número da versão da API (opcional; a requisição funciona também sem ele)Para facilitar a migração futura para os endpoints oficiais da Anthropic, recomenda-se incluí-lo:Exemplo: 2025-10-01

Body

string
padrão:"claude-sonnet-4-6"
obrigatório
Model name
  • claude-opus-4-8 - Claude Opus 4.8 flagship model
  • claude-opus-4-7 - Claude Opus 4.7 flagship model
  • claude-opus-4-6 - Claude Opus 4.6 flagship model
  • claude-sonnet-4-6 - Claude Sonnet 4.6 balanced version
  • claude-opus-4-5-20251101 - Claude Opus 4.5 model
array
obrigatório
Lista de mensagensArray de mensagens para o modelo gerar a próxima resposta. Cada mensagem contém os campos role e content.💡 Preenchimento rápido (área Try it):
  1. Clique em ”+ Add an item” para adicionar uma mensagem
  2. Em role, informe: user (mensagem do usuário) ou assistant (resposta da IA, para múltiplas rodadas)
  3. Em content, informe o texto da sua mensagem
Mensagem única do usuário:
Conversa em múltiplas rodadas:
Resposta do assistente pré-preenchida:
integer
obrigatório
Máximo de tokens a serem gerados (obrigatório, alinhado com a API oficial da Anthropic)Número máximo de tokens a serem gerados antes de parar. O modelo pode parar antes de atingir esse limite.Modelos diferentes possuem valores máximos distintos; consulte a documentação do modelo. Mínimo: 1
object
Configuração do extended thinkingQuando ativado, a resposta content pode conter blocos thinking. Recomendado: usar o nome de modelo padrão + este parâmetro, em vez de aliases de modelo -thinking no lado da plataforma, para facilitar a migração para os endpoints oficiais sem alterar o código.Em conversas multi-rodada que precisem reenviar blocos thinking, deve devolver integralmente o signature; caso contrário, o upstream rejeitará a requisição.
string | array
Prompt do sistemaOs prompts do sistema definem o papel, a personalidade, os objetivos e as instruções do Claude.Formato string:
Formato estruturado:
number
Parâmetro de temperatura, faixa 0–1Controla a aleatoriedade da saída:
  • Valores baixos (por exemplo, 0.2): mais determinístico, conservador
  • Valores altos (por exemplo, 0.8): mais aleatório, criativo
Padrão: 1.0
number
Parâmetro de amostragem por núcleo (nucleus sampling), faixa 0–1Utiliza amostragem por núcleo. Recomenda-se usar temperature OU top_p, não ambos.Padrão: 1.0
integer
Amostragem Top-KAmostra apenas a partir das K principais opções, removendo respostas de baixa probabilidade da “cauda longa”.Recomendado apenas para casos de uso avançados.
boolean
Habilitar streamingQuando true, usa Server-Sent Events (SSE) para transmitir as respostas em streaming.Padrão: false
array
Sequências de paradaSequências de texto personalizadas que fazem o modelo parar de gerar.Máximo de 4 sequências.Exemplo: ["\n\nHuman:", "\n\nAssistant:"]
object
MetadadosObjeto de metadados para a requisição.Inclui:
  • user_id: identificador do usuário
array
Definições de ferramentasLista de ferramentas que o modelo pode usar para concluir as tarefas.Exemplo de ferramenta de função:
Tipos de ferramentas suportadas:
  • Ferramentas de função personalizadas
  • Ferramenta de uso do computador (computer_20241022)
  • Ferramenta de edição de texto (text_editor_20241022)
  • Ferramenta Bash (bash_20241022)
object
Estratégia de escolha de ferramentaControla como o modelo usa as ferramentas:
  • {"type": "auto"}: decisão automática (padrão)
  • {"type": "any"}: deve usar uma ferramenta
  • {"type": "tool", "name": "tool_name"}: usar uma ferramenta específica

Resposta

string
Identificador único da mensagemExemplo: "msg_013Zva2CMHLNnXjNJJKqJ2EF"
string
Tipo do objetoSempre "message"
string
PapelSempre "assistant"
array
Array de blocos de conteúdocontent distingue os tipos de bloco por type. Uma única resposta pode conter vários blocos (por exemplo thinking + text quando thinking está ativado).Bloco text:
Bloco tool_use:
caller é um campo novo do upstream, ainda não documentado oficialmente; ignore-o na análise.
Bloco thinking (aparece quando o corpo da requisição inclui o parâmetro thinking):
Em conversas multi-rodada, ao reenviar blocos thinking, deve devolver integralmente o signature; caso contrário, o upstream rejeitará a requisição.
Não assuma que content[0] é texto. Com thinking ativado, content[0] pode ser um bloco thinking. Percorra e filtre:
string
Modelo que processou a requisiçãoExemplo: "claude-sonnet-4-6"
string
Motivo da paradaValores possíveis:
  • end_turn: conclusão natural
  • max_tokens: atingiu o limite máximo de tokens
  • stop_sequence: encontrou uma sequência de parada
  • tool_use: invocou uma ferramenta
string | null
Sequência de parada acionadaA sequência de parada gerada, se houver; caso contrário, null
object | null
Campo mais recente da Anthropic; null em requisições habituais
object
Estatísticas de uso de tokens (estrutura completa não streamada)

Exemplos de uso

Conversa simples

Conversa em múltiplas rodadas

Uso de prompts do sistema

Resposta em streaming

Uso de ferramentas

Compreensão visual

Imagem em Base64

Boas práticas

1. Engenharia de prompts

Definição clara do papel:
Saída estruturada:

2. Tratamento de erros

3. Otimização de tokens

4. Pré-preenchimento de respostas

Tratamento de respostas em streaming

Streaming em Python

Streaming em JavaScript

Diferenças da plataforma e pontos de integração

Resposta sem envelope

Em caso de sucesso, POST /v1/messages devolve diretamente o objeto message da Anthropic, sem envelope {code, data}. Assim, os SDKs oficiais, Claude Code, Cline, etc. permanecem compatíveis 1:1.

Formato de erro (única diferença substancial em relação ao oficial)

Em relação à API oficial da Anthropic: o nível raiz não tem "type": "error"; error.type é fixo em apimart_error, e não tipos semânticos como invalid_request_error. Recomendação de integração: não baseie a lógica de retry em error.type; use o código de estado HTTP + error.code: Para suporte, forneça: o request id no final de error.message, e o cabeçalho de resposta x-oneapi-request-id.

Streaming SSE

Adicione "stream": true à requisição. A sequência de eventos é idêntica à oficial: message_startcontent_block_startpingcontent_block_delta (várias vezes) → content_block_stopmessage_deltamessage_stop ⚠️ A estrutura de usage difere entre stream e não stream: message_delta.usage normalmente tem apenas 4 campos de tokens, sem cache_creation, service_tier, inference_geo. Analise-os em separado ou trate todos os campos como opcionais.

Endpoint não implementado

POST /v1/messages/count_tokens não está implementado e devolve 404. A chamada client.messages.count_tokens() do SDK oficial falhará. Para estimar tokens, faça-o localmente ou leia usage.input_tokens na resposta.

Ignorar campos desconhecidos

Esta API retransmite o upstream tal como vem; a Anthropic pode adicionar campos a qualquer momento (p.ex. stop_details, inference_geo, caller, output_tokens_details). Não ative um esquema estrito:
  • Go: não use DisallowUnknownFields()
  • Pydantic: não use extra="forbid"
  • TypeScript / Zod: use .passthrough() em vez de .strict()

Recomendação de nomes de modelos

Os modelos homónimos com o sufixo -thinking são aliases de extensão da plataforma. Recomendado: usar o nome de modelo padrão sem sufixo + o parâmetro thinking no corpo da requisição, para facilitar a migração para os endpoints oficiais. Os restantes campos do corpo da requisição estão alinhados com o oficial: model, messages, max_tokens (obrigatório), system, temperature, top_p, top_k, stop_sequences, stream, tools, tool_choice, thinking, metadata. A semântica segue a Messages API da Anthropic.

Observações importantes

  1. Segurança da chave de API:
    • Armazene as chaves de API em variáveis de ambiente
    • Nunca insira chaves diretamente no código-fonte
    • Faça a rotação das chaves regularmente
  2. Limite de taxa:
    • Esteja atento aos limites de taxa da API
    • Implemente mecanismos de retry (segundo o código de estado HTTP)
    • Use exponential backoff
  3. Gerenciamento de tokens:
    • Monitore o consumo de tokens (leia usage)
    • Otimize o tamanho dos prompts
    • Use valores adequados de max_tokens
    • Com thinking ativado, output_tokens já inclui o thinking; não fature em duplicado
  4. Seleção de modelo:
    • Opus: tarefas complexas, que exigem raciocínio profundo
    • Sonnet: desempenho e custo equilibrados
    • Haiku: resposta rápida, tarefas simples
  5. Análise do conteúdo:
    • Percorra content para blocos type == "text"; não fixe content[0].text
    • Se o modelo devolver JSON envolvido num bloco de código Markdown, é saída do modelo e não envelope da API (veja a FAQ abaixo)
  6. Filtragem de conteúdo:
    • Valide a entrada do usuário
    • Filtre informações sensíveis
    • Implemente moderação de conteúdo

FAQ

O text de content veio como bloco de código ```json ... ``` — como remover?

Isto não é um problema de estrutura da API. O campo text contém o conteúdo bruto gerado pelo modelo: se o modelo conclui que você quer JSON, costuma envolvê-lo num bloco de código Markdown. A API não reescreve (e não deve reescrever) a saída do modelo. Para obter dados estruturados limpos, há três abordagens corretas (da mais confiável à menos):
  1. Usar tools para forçar saída estruturada — a mais confiável; o campo input já é um objeto parseado:
  1. Prefill a mensagem do assistant, para o modelo continuar a partir de {:
  1. Exigir no system prompt: «emita apenas JSON, sem bloco de código Markdown».
Não se recomenda remover o code fence com regex — se o modelo ocasionalmente não incluir a cerca, o parsing falha.