Saltar al contenido principal
Formato de error Lerian Consignado devuelve los errores como detalles de problema RFC 9457 con el tipo de contenido application/problem+json:
Definiciones de campos
  • type – Un URI que identifica el error en el catálogo de errores de Lerian. Se construye como https://errors.lerian.studio/v1/<code>.
  • title – El texto del estado HTTP (por ejemplo, Unprocessable Entity).
  • status – El código de estado HTTP.
  • detail – Una explicación legible de esta ocurrencia. En una respuesta 5xx, Consignado sanea el detail a internal error, de modo que una causa interna no queda expuesta en el cuerpo. Un código 5xx que nombra una falla upstream o un resultado desconocido conserva un detail escrito para ti, como DATAPREV_TIMEOUT. Distingue por code y por el estado, no por el detail.
  • code – Un identificador estable para el error. Las tablas siguientes muestran los códigos CLT-NNNN y los códigos con nombre que comparten varias operaciones. Algunas operaciones responden con códigos propios, como CURSOR_EXPIRED en el barrido del inventario de registros. Consulta Códigos por operación. Una solicitud que no supera la validación de esquema no lleva code: responde 422 con el detail validation failed, o 400 cuando el cuerpo no se puede interpretar, y la lista errors nombra cada campo.
  • errors – Lista opcional de detalles de error individuales, cada uno con un location, un message y un value.
  • instance – El trace ID de la solicitud, cuando el gateway la rastreó. Indícalo cuando reportes una falla a Lerian.
  • upstream – El error que devolvió un sistema upstream y que el gateway retransmite. Viene de Dataprev en las operaciones del riel, y del Streaming Hub en las operaciones de suscripción. Contiene el code y el message de ese sistema, y sobrevive al saneamiento 5xx que borra detail. Consulta Códigos de motivo de Dataprev.
  • refusal – En un rechazo de oferta: el motivo que el gateway registró para la oferta, con su source, field, rule y detail. Un rechazo de Dataprev también lleva el code de Dataprev.

400: Solicitud incorrecta


401: No autorizado


403: Prohibido


404: No encontrado


409: Conflicto


CLT-0007 con el detail an identical request is already in flight marca una solicitud que el gateway no ha terminado. Reintenta esa solicitud con la misma clave de idempotencia. Los conflictos de comando responden con un código propio en lugar de CLT-0007, de modo que un cliente pueda distinguirlos. Lee code y detail juntos antes de reintentar. Estas grafías de código son parte del contrato de transmisión y no cambian. Después de DATAPREV_CREDENTIAL_REQUIRED, carga el certificado de Dataprev, las credenciales de OAuth y el código de solicitante del tenant, y luego envía la solicitud de nuevo. Después de DATAPREV_CREDENTIAL_REVOKED, carga un nuevo certificado y un nuevo cliente de OAuth juntos con PUT /v1/credentials/dataprev. Después de DATAPREV_CREDENTIAL_REJECTED, corrige las credenciales de cliente OAuth del tenant, y luego envía una lectura de nuevo. Una escritura puede haber dejado su comando detenido: consulta Operar Lerian Consignado antes de enviarla de nuevo.

410: Ya no disponible


El barrido paginado del inventario de registros emite un cursor con una ventana de reintento limitada.

413: Entidad de la solicitud demasiado grande


Un cuerpo de averbação que lleva la CCB firmada, el paquete de evidencias, la evidencia de firma o data_hora_assinatura se rechaza. Responde 413 con 1 MiB o más, y 422 con el detail validation failed por debajo de eso. Envíalos a POST /v1/consignado/contracts/{numero_contrato}/ccb-attachment cuando Dataprev acepte la averbação.

422: Entidad no procesable


Algunos rechazos responden con un código con nombre en lugar de CLT-0006. Nada llegó a Dataprev. La descripción dice qué hacer a continuación. Los códigos de contabilización, de FIRST_DEDUCTION_BEFORE_COMPETENCIA a CONTRACT_NOT_BOOKABLE, aplican solo a un contrato enviado con el bloque de contabilización. Una averbação responde todos los códigos de contabilización, excepto FORMALIZATION_DEADLINE_EXCEEDED. Su documentación responde solo DECLARED_DATES_OUT_OF_ORDER y FORMALIZATION_DEADLINE_EXCEEDED. Una importación de contrato con booking responde todos los códigos de contabilización, excepto FIRST_DEDUCTION_BEFORE_COMPETENCIA. Una averbação con el bloque de contabilización también responde RATE_OUTSIDE_PRODUCT_RANGE. Un comando enviado de nuevo con una clave de idempotencia que una solicitud anterior ya consumió puede responder uno de cuatro códigos con nombre. La solicitud anterior puede haber llegado ya a Dataprev. No envíes el comando de nuevo, ni con esta clave ni con una nueva. Lee el estado actual del registro que el comando cambia. La respuesta a la subasta de portabilidad es la excepción: su referencia explica cómo un reenvío con una clave nueva revela el resultado.

429: Demasiadas solicitudes


Espera el tiempo que indica el header Retry-After y luego envía la solicitud de nuevo.

500: Error interno del servidor


501: No implementado


Un 501 responde a una operación que tu despliegue no habilitó. Las rutas permanecen montadas, de modo que la respuesta llega por solicitud en lugar de como una ruta ausente. Estas operaciones responden 501 hasta que tu despliegue las habilite:
  • las descargas de artefactos de contrato
  • las correcciones de contrato
  • el envío de ofertas
  • las operaciones que llegan a Dataprev
La revocación de credenciales de Dataprev responde 501 en un despliegue cuyas credenciales son estáticas. El detail muestra internal error, porque Consignado sanea el detail en una respuesta 5xx. La revocación de credenciales es la excepción: su detail dice que las credenciales son estáticas. Distingue por el estado.

502: Gateway incorrecto


503: Servicio no disponible


Una respuesta DATAPREV_UNAVAILABLE o DATAPREV_TIMEOUT también lleva upstream cuando Dataprev envió su propio código y mensaje.

504: Timeout del gateway


Códigos por operación


Algunas operaciones responden con códigos propios, nombrados a partir de la operación: FUNDO_*, ORIGINADOR_*, CESSAO_*, CEDED_CREDIT_*, SALDO_DEVEDOR_*, REGISTRO_B3_*, y los códigos de cursor y de filtro de las operaciones de listado. La referencia de la API enumera todos los códigos en el campo code de su esquema de error. Las operaciones del código de instrumento B3, GET y PATCH /v1/consignado/contracts/{numero_contrato}/registro-b3, responden con estos códigos.

Códigos de motivo de Dataprev


Consignado retransmite los códigos de motivo de Dataprev en lugar de asignarlos a códigos propios. Esto mantiene un rechazo legible frente a lo que Dataprev dijo. Lee cada código de motivo contra la especificación de Dataprev, no contra esta página. Dataprev puede publicar un código que esta página no incluye, y el gateway igual te lo entrega. Te llegan en dos lugares. En un rechazo. El miembro upstream lleva el code y el message propios de Dataprev. Un rechazo con varios códigos los lista separados por comas. El miembro contiene los códigos y las frases de Dataprev, con longitud acotada, no un cuerpo de respuesta. Un 422 lo lleva para un rechazo determinístico. DATAPREV_UNAVAILABLE y DATAPREV_TIMEOUT lo llevan para un fallo de reintentar más tarde. Un rechazo de Dataprev a un comando en upstream queda retenido bajo su clave de idempotencia. Un refusal de oferta también, sea cual sea su source. La misma clave devuelve el mismo rechazo, así que envía una solicitud corregida con una clave nueva. Una oferta rechazada con source dataprev también retiene su solicitação, así que cualquier oferta nueva para esa solicitação responde BID_SOLICITACAO_TAKEN. Un rechazo que el gateway hace por su cuenta, sin upstream y sin miembro refusal de oferta, no retiene la clave, así que una solicitud corregida puede ir con la misma clave. Una ejecución de garantía FGTS y un comando que responde códigos RAIL_COMMAND_* son la excepción: retienen la clave desde antes de llamar a Dataprev. Cuando un reenvío responde que una solicitud anterior ya tiene la clave, como IDEMPOTENCY_KEY_REUSE o RAIL_COMMAND_PAYLOAD_MISMATCH, sigue la instrucción de ese código. En las respuestas de contrato y margen. Varios campos de respuesta emparejan un código de motivo de Dataprev con la etiqueta propia de Dataprev para él. Una lectura de margen publica blockType y ineligibilityReason, que forman el par code y description. Una lectura de contrato publica motivo_exclusao, origem_averbacao, origem_exclusao, portabilidade_situacao, y situacao_bloqueio_garantia, que lo forman como codigo y descricao. Cada campo contiene un código numérico y el texto que Dataprev devolvió junto a él. Trata el conjunto como abierto. Asigna los códigos de motivo sobre los que actúa tu integración, y transmite el resto con sus etiquetas, de modo que un código que aún no hayas asignado siga siendo legible para un operador.