Skip to main content
Every failed /v1 request returns an RFC 9457 problem document with the content type application/problem+json. Every problem carries a stable code: branch on it, never on the human text.

The problem document

The document always has exactly these seven fields, and no others.
Handle errors in two levels: first the code values your integration knows, then the HTTP status as a fallback for any code it does not know yet. New codes can appear inside /v1 (see Versioning).
Unexpected failures always become a 500 with the code common.internal_error. Internal details, stack traces and database messages never appear in a response.

Codes a /v1 caller can receive

Invalid request causes

Same answer, different reasons

Several answers deliberately cover more than one situation, so that the API never reveals what exists in another dental clinic:
  • A record of another dental clinic and a record that does not exist return the same 404.
  • Every problem with a key returns the same 401.
Do not build logic that tries to tell these cases apart.

Errors on /mcp

The MCP endpoint https://api.muveya.com/mcp fails in three different ways. 1. Before the MCP session starts. A missing, expired or invalid OAuth access token returns 401 with a WWW-Authenticate link to protected resource metadata. An API key is not accepted. 2. Inside a tool call. A tool that fails still returns a normal JSON-RPC response. Its result has isError: true and its text is a problem document:
  • In a tool result, instance is /mcp# followed by the tool name.
  • The title and detail of tool results are in English.
  • The requestId identifies that MCP request. Keep it from the tool result when you report a problem.
  • Arguments that do not match the tool’s input schema, and unknown tool names, also come back as a result with isError: true, but with a plain text message instead of a problem document.
3. Protocol errors. These are JSON-RPC error objects, not problem documents: See Connect an MCP client for a correct request.

Failures that are not HTTP errors

An export that fails after it was accepted does not return an error status. Its job moves to "status": "failed" with a machine-readable error reason. See Exports.