application/problem+json:
type: un URI que identifica el tipo de error, formado porhttps://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 para el 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 siguiente).entityType: la entidad con la que se relaciona el error (por ejemplo,Rule). Solo está presente cuando corresponde.message: el motivo en lenguaje natural, expuesto tal cual como campo de primer nivel. Solo está presente en las respuestas413 Payload Too Largey504 Gateway Timeout. El resto de los errores lo omiten.
En los errores del lado del servidor (HTTP 5xx),
title y detail llevan valores genéricos para que las causas internas nunca se filtren. Usa code y type para identificar el error. En los 504 por timeout, el campo message de primer nivel sigue llevando el motivo específico.0009 con el título Validation Error y un detail que nombra el campo y la restricción específicos, 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. Las emite un middleware que se ejecuta antes de la capa de API. Fallos de autenticación: una clave de API ausente o inválida devuelve HTTP 401 con "code": "Unauthenticated", "title": "Unauthorized", y "message": "API Key missing or invalid". Haz coincidir la cadena literal Unauthenticated. Un token Bearer que se analiza correctamente pero carece del claim sub requerido devuelve HTTP 401 con "code": "0474". Capacidad de tenant: el código 0466 devuelve HTTP 503 en la misma forma plana.Errores generales
Cualquier endpoint de la API de Tracer puede devolver estos errores.
El código
0009 también aparece con el título Validation Error cuando la validación en el nivel de campo rechaza una solicitud. Consulta la nota anterior.
Los endpoints de validación y de reserva devuelven el código 0143 con HTTP 413 cuando el cuerpo de la solicitud supera el límite de 100KB. El motivo también aparece en el campo message de primer nivel. La API de Tracer devuelve el código 0497 con HTTP 431 cuando los headers de la solicitud son demasiado grandes. Devuelve el código 0484 con HTTP 404 para una ruta que el servicio no atiende. Devuelve 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 metadatos
Estos errores provienen del mapa
metadata de una solicitud de validación (POST /v1/validations) y de una solicitud de reserva (POST /v1/reservations).
La API devuelve HTTP
400 cuando una clave de metadatos supera los 64 caracteres, o cuando una solicitud tiene más de 50 entradas de metadatos.
Errores de expresión CEL
Escribes las reglas como expresiones CEL (Common Expression Language). Estos errores aparecen al crear, actualizar o evaluar la expresión de una regla.
Errores de regla
Errores de límite
| 0371 | Caracteres no válidos en el nombre del límite | El nombre del límite contiene caracteres no válidos. |
| 0372 | Caracteres no válidos en la descripción del límite | La descripción del límite contiene caracteres no válidos. |
| 0373 | ID de límite no válido | El ID del límite no es válido o es nulo. |
| 0378 | Falló la verificación del límite | Falló la verificación del límite. |
| 0379 | Entrada de límite nula | La entrada del límite no puede ser nula. |
| 0380 | Campo inmutable de límite | No se puede modificar un campo inmutable (limitType, asset). |
| 0438 | Discrepancia en la ventana de tiempo del límite | ActiveTimeStart y activeTimeEnd deben estar ambos definidos o ambos ser nulos. |
| 0442 | El nombre del límite ya existe | El nombre del límite ya existe. |
| 0447 | Formato de inicio personalizado no válido | Formato de customStartDate no válido, se esperaba RFC3339. |
| 0448 | Formato de fin personalizado no válido | Formato de customEndDate no válido, se esperaba RFC3339. |
| 0449 | Fechas personalizadas obligatorias | CustomStartDate y customEndDate son obligatorios para el limitType CUSTOM. |
Errores de evento de auditoría
Errores de solicitud de validación
Los endpoints de validación de transacciones (
POST /v1/validations y las consultas de validación) devuelven estos errores.
La API devuelve los códigos
0422 y 0433 con HTTP 504 Gateway Timeout: 0422 cuando la evaluación de una validación supera su plazo, 0433 cuando lo supera una consulta de lista de validaciones. Como en todas las respuestas 5xx, detail lleva un valor genérico. El campo message de primer nivel lleva el motivo específico.
Errores de reserva
Los endpoints de reserva de uso (
/reservations) devuelven estos errores. Forman la superficie de dos fases de reservar, confirmar y liberar. Las solicitudes de reserva también pueden devolver los errores generales y de solicitud de validación indicados antes.
| 0487 | Tenant obligatorio en la reserva | Reserva: el id del tenant es obligatorio en la superficie de reserva multi-tenant. |
Errores de multi-tenant y autenticación
La instancia devuelve HTTP 503 con un header
Retry-After cuando alcanza su tope de workers de tenant por pod. Los clientes deben aplicar backoff y reintentar. Un token Bearer que se analiza correctamente pero carece del claim sub requerido devuelve 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 obligatoria o es incompatible. Aparecen en los logs de inicio e impiden que el servicio arranque. Nunca llegan a los consumidores de la API /v1/*.
Errores del readiness probe
El endpoint operativo
/readyz y el ciclo de vida del worker-supervisor exponen estos códigos. Aparecen en el campo error de la respuesta JSON de /readyz (que lleva solo el código), no en las respuestas de la API /v1/*. El title y el message siguientes describen cada código como referencia para el operador.
El ciclo de /readyz verifica cinco dependencias. Siempre verifica postgres y rule_cache. Verifica redis y tenant_manager solo en modo multi-tenant, y las omite en caso contrario. streaming es informativo. Aparece en las verificaciones y en las métricas, pero nunca fuerza un 503.

