Skip to main content
La API de Tracer devuelve los errores como un objeto de detalles de problema RFC 9457, servido con el tipo de contenido application/problem+json:
Definiciones de campos
  • type: un URI que identifica el tipo de error, formado por https://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 columna message.
  • 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 literal Unauthenticated (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 respuestas 413 Payload Too Large y 504 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.
Validación en el nivel de campo Los fallos de validación de campo en el nivel de estructura devuelven el código 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.