Skip to main content
Toda solicitud fallida a /v1 devuelve un documento de problema RFC 9457 con el tipo de contenido application/problem+json. Todo problema tiene un code estable: decide según ese código, nunca según el texto para personas.

El documento de problema

Accept-Language: es
El documento siempre tiene exactamente estos siete campos, y ningún otro.
Maneja los errores en dos niveles: primero los valores de code que tu integración conoce y luego el status HTTP como respaldo para cualquier código que todavía no conozca. Pueden aparecer códigos nuevos dentro de /v1 (consulta Versionado).
Las fallas inesperadas siempre se convierten en un 500 con el código common.internal_error. Los detalles internos, trazas y mensajes de base de datos nunca aparecen en una respuesta.

Códigos que puede recibir quien llama a /v1

Causas del error 400

Misma respuesta, distintas razones

Algunas respuestas cubren a propósito más de una situación, para que la API nunca revele qué existe en otra clínica dental:
  • Un registro de otra clínica dental y un registro que no existe devuelven el mismo 404.
  • Todo problema con una clave devuelve el mismo 401.
No construyas lógica que intente distinguir estos casos.

Errores en /mcp

El endpoint MCP https://api.muveya.com/mcp falla de tres maneras distintas. 1. Antes de que empiece la sesión MCP. Un token de acceso OAuth ausente, vencido o no válido devuelve 401 con un enlace WWW-Authenticate a los metadatos del recurso protegido. No se acepta una clave de API. 2. Dentro de una llamada a una herramienta. Una herramienta que falla devuelve de todos modos una respuesta JSON-RPC normal. Su resultado tiene isError: true y su texto es un documento de problema:
  • En el resultado de una herramienta, instance es /mcp# seguido del nombre de la herramienta.
  • El title y el detail de los resultados de herramientas están en inglés.
  • El requestId identifica esa solicitud MCP. Tómalo del resultado de la herramienta y consérvalo para cuando nos informes un problema.
  • Los argumentos que no cumplen el esquema de entrada de la herramienta, y los nombres de herramienta desconocidos, también vuelven como un resultado con isError: true, pero con un mensaje de texto simple en lugar de un documento de problema.
3. Errores de protocolo. Son objetos de error JSON-RPC, no documentos de problema: Consulta Conectar un cliente para ver una solicitud correcta.

Fallas que no son errores HTTP

Una exportación que falla después de haber sido aceptada no devuelve un estado de error. Su trabajo pasa a "status": "failed" con un motivo error legible por máquina. Consulta Exportaciones.

Páginas relacionadas