Skip to main content
Toda requisição com falha a /v1 retorna um documento de problema RFC 9457 com o tipo de conteúdo application/problem+json. Todo problema tem um code estável: decida por ele, nunca pelo texto destinado a pessoas.

O documento de problema

Accept-Language: pt
O documento sempre tem exatamente estes sete campos, e nenhum outro.
Trate os erros em dois níveis: primeiro os valores de code que sua integração conhece e depois o status HTTP como alternativa para qualquer código que ela ainda não conheça. Novos códigos podem surgir dentro de /v1 (veja Versionamento e estabilidade).
Falhas inesperadas sempre viram um 500 com o código common.internal_error. Detalhes internos, stack traces e mensagens de banco de dados nunca aparecem em uma resposta.

Códigos que quem chama /v1 pode receber

Causas do erro 400

Mesma resposta, motivos diferentes

Algumas respostas cobrem de propósito mais de uma situação, para que a API nunca revele o que existe em outra clínica odontológica:
  • Um registro de outra clínica odontológica e um registro que não existe retornam o mesmo 404.
  • Todo problema com uma chave retorna o mesmo 401.
Não crie lógica que tente distinguir esses casos.

Erros no /mcp

O endpoint MCP https://api.muveya.com/mcp falha de três formas diferentes. 1. Antes de a sessão MCP começar. Um token de acesso OAuth ausente, expirado ou inválido retorna 401 com um link WWW-Authenticate para os metadados do recurso protegido. Uma chave de API não é aceita. 2. Dentro de uma chamada de ferramenta. Uma ferramenta que falha ainda retorna uma resposta JSON-RPC normal. O resultado tem isError: true e o texto é um documento de problema:
  • No resultado de uma ferramenta, instance é /mcp# seguido do nome da ferramenta.
  • O title e o detail dos resultados de ferramentas vêm em inglês.
  • O requestId identifica aquela requisição MCP. Guarde o do resultado da ferramenta quando relatar um problema.
  • Argumentos que não seguem o esquema de entrada da ferramenta, e nomes de ferramenta desconhecidos, também voltam como um resultado com isError: true, mas com uma mensagem de texto simples em vez de um documento de problema.
3. Erros de protocolo. São objetos de erro JSON-RPC, não documentos de problema: Veja Conectar um cliente para uma requisição correta.

Falhas que não são erros HTTP

Uma exportação que falha depois de aceita não retorna um status de erro. O trabalho passa para "status": "failed" com um motivo error legível por máquina. Veja Exportações do resumo gerencial.

Páginas relacionadas