application/problem+json:
type: Un URI que identifica el tipo de error, construido comohttps://errors.lerian.studio/v1/seguido del código de error.title: Un resumen breve del problema.status: El código de estado HTTP de la respuesta.detail: Orientación detallada para resolver el error. Las tablas siguientes muestran este contenido en la columnamessage.code: Un identificador único y estable del error. Suele ser una cadena numérica de cuatro dígitos tomada del registro de errores compartido de la plataforma (por ejemplo,0347); los fallos de autenticación son la excepción y usan la cadena literalUnauthenticated(consulta la nota más abajo).entityType: La entidad a la que se refiere el error (por ejemplo,Rule). Solo está presente cuando aplica.message: La razón legible por humanos, expuesta textualmente como campo de nivel superior. Solo está presente en las respuestas413 Payload Too Largey504 Gateway Timeout; el resto de los errores lo omite.
En los errores del lado del servidor (HTTP 5xx),
title y detail se sanean con valores genéricos para que las causas internas nunca se filtren. Usa code y type para identificar el error. En los timeouts 504, el campo de nivel superior message sigue llevando la razón específica.0009 con el título Validation Error y un detail que nombra el campo y la restricción concretos; por ejemplo, transactionType must be one of [CARD WIRE PIX CRYPTO].
Ejemplos:
Dos familias de respuestas conservan una forma plana heredada
{"code", "title", "message"} en lugar del objeto de detalles de problema, porque las emite un middleware que se ejecuta antes de la capa de la API. Fallos de autenticación: una API key ausente o inválida devuelve HTTP 401 con "code": "Unauthenticated", "title": "Unauthorized" y "message": "API Key missing or invalid" — compara con la cadena literal Unauthenticated; un token Bearer que se analiza pero carece del claim sub requerido devuelve HTTP 401 con "code": "0474". Capacidad de tenants: el código 0466 devuelve HTTP 503 con la misma forma plana.Errores generales
Estos errores puede devolverlos cualquier endpoint de la API de Tracer.
El código
0009 también aparece con el título Validation Error cuando la validación a nivel de campo rechaza una solicitud — consulta la nota anterior.
El código 0143 se devuelve con HTTP 413 cuando el cuerpo de una solicitud supera el límite de 100KB en los endpoints de validación y de reservas; la razón también aparece en el campo de nivel superior message. El código 0497 se devuelve con HTTP 431 cuando las cabeceras de la solicitud son demasiado grandes. El código 0484 se devuelve con HTTP 404 para una ruta que el servicio no sirve, y el código 0485 con HTTP 405 para un método que la ruta no acepta.
Errores de fecha y hora
Errores de paginación
Errores de metadata
Estos errores los genera el mapa
metadata de una solicitud de validación (POST /v1/validations) y de una solicitud de reserva (POST /v1/reservations).
Una clave de metadata de más de 64 caracteres, o más de 50 entradas de metadata en una misma solicitud, se rechaza con HTTP
400.
Errores de expresión CEL
Las reglas se escriben como expresiones CEL (Common Expression Language). Estos errores se generan cuando una expresión de regla se crea, se actualiza o se evalúa.
Errores de reglas
Errores de límites
Errores de eventos de auditoría
Errores de solicitud de validación
Estos errores los devuelven los endpoints de validación de transacciones (
POST /v1/validations y las consultas de validación).
Los códigos
0422 y 0433 se devuelven con HTTP 504 Gateway Timeout — 0422 cuando una evaluación de validación supera su plazo, 0433 cuando lo hace una consulta de listado de validaciones. Como en todas las respuestas 5xx, detail se sanea; la razón específica viaja en el campo de nivel superior message.
Errores de reserva
Estos errores los devuelven los endpoints de reserva de uso (
/reservations), la superficie de dos fases de reservar / confirmar / liberar. Las solicitudes de reserva también pueden devolver los errores generales y de solicitud de validación indicados arriba.
Errores de multi-tenant y autenticación
La instancia devuelve HTTP 503 con un encabezado
Retry-After cuando alcanza su tope de workers por tenant y por pod; los clientes deben esperar y reintentar. Un token Bearer que se analiza pero carece del claim sub requerido se rechaza con HTTP 401.
Errores de arranque de multi-tenant
Estos códigos aparecen solo al iniciar el servicio, cuando
MULTI_TENANT_ENABLED=true y falta una configuración requerida o es incompatible. Aparecen en los registros de arranque e impiden que el servicio inicie; nunca llegan a los consumidores de la API /v1/*.
Errores de sonda de disponibilidad
Estos códigos los expone el endpoint operativo
/readyz y el ciclo de vida del supervisor de workers. Aparecen en el campo error de la respuesta JSON de /readyz —que lleva solo el código— y no en las respuestas de la API /v1/*. El title y el message de abajo describen cada código como referencia para el operador.
El ciclo de /readyz sondea cinco dependencias: postgres y rule_cache siempre; redis y tenant_manager solo en modo multi-tenant (omitidas en caso contrario); streaming es consultiva — aparece en las comprobaciones y métricas, pero nunca fuerza un 503.

