application/problem+json:
type– Un URI que identifica el error en el catálogo de errores de Lerian. Se construye comohttps://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 respuesta5xx, Consignado sanea el detail ainternal error, de modo que una causa interna no queda expuesta en el cuerpo. Un código5xxque nombra una falla upstream o un resultado desconocido conserva un detail escrito para ti, comoDATAPREV_TIMEOUT. Distingue porcodey por el estado, no por el detail.code– Un identificador estable para el error. Las tablas siguientes muestran los códigosCLT-NNNNy los códigos con nombre que comparten varias operaciones. Algunas operaciones responden con códigos propios, comoCURSOR_EXPIREDen el barrido del inventario de registros. Consulta Códigos por operación. Una solicitud que no supera la validación de esquema no llevacode: responde422con el detailvalidation failed, o400cuando el cuerpo no se puede interpretar, y la listaerrorsnombra cada campo.errors– Lista opcional de detalles de error individuales, cada uno con unlocation, unmessagey unvalue.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 elcodey elmessagede ese sistema, y sobrevive al saneamiento5xxque borradetail. Consulta Códigos de motivo de Dataprev.refusal– En un rechazo de oferta: el motivo que el gateway registró para la oferta, con susource,field,ruleydetail. Un rechazo de Dataprev también lleva elcodede Dataprev.existing_id– En un rechazosubscription_name_taken, el id de la suscripción activa en tu alcance que tiene ese nombre.error_classystatus_code– En una edición de suscripción que responde422conupstream.codedestination_probe_failed, la clase de la sonda que falló y, cuando el destino respondió, su estado HTTP.
400: Solicitud incorrecta
401: No autorizado
403: Prohibido
Un gateway cuya licencia de Lerian falló rechaza toda solicitud nueva en el puerto principal con
403 mientras se apaga, excepto /health y /version. Ese cuerpo no es problem details: es un JSON con code, title y message. Para sus códigos, consulta la lista de errores del License Manager. En un despliegue BYOC, revisa LICENSE_KEY o LICENSE_FILE_PATH.
404: No encontrado
Una primera corrección de CCB para un número de contrato que el tenant nunca registró ni importó responde este código, y el gateway no retiene nada. Un contrato que salió del registro todavía acepta correcciones.
Una exclusión de un contrato que tiene una averbação contabilizada en el gateway, pero salió del registro, responde este código con el detalle
the gateway holds neither a booked averbação nor a live M015 obligation of this contract for this tenant. No se envía nada a Dataprev.
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. El client id puede seguir siendo el mismo, pero el secreto del cliente debe generarse de nuevo en 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.
412: Precondición fallida
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 VERSION_ADMITS_NO_PESSOA_FISICA, aplican solo a una solicitud enviada con el bloque de contabilización. El gateway verifica la versión en este orden: LOAN_PRODUCT_VERSION_UNKNOWN, VERSION_ADMITS_NO_PESSOA_FISICA y luego RATE_OUTSIDE_PRODUCT_RANGE. MATRICULA_DIFFERS_FROM_PROPOSAL aplica a una averbação con o sin el bloque de contabilización.
Cada superficie responde estos códigos de contabilización:
- Una averbação: todos los códigos de contabilización, excepto
FORMALIZATION_DEADLINE_EXCEEDED. - La documentación de una averbação: solo
DECLARED_DATES_OUT_OF_ORDERyFORMALIZATION_DEADLINE_EXCEEDED. - Una importación de contrato con
booking: todos los códigos de contabilización, exceptoFIRST_DEDUCTION_BEFORE_COMPETENCIA. - Un refinanciamento con
booking: todos los códigos de contabilización, exceptoFORMALIZATION_DEADLINE_EXCEEDED. - Una averbação de portabilidad con
booking: todos los códigos de contabilización, exceptoFIRST_DEDUCTION_BEFORE_COMPETENCIAyFORMALIZATION_DEADLINE_EXCEEDED.
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
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, DATAPREV_TIMEOUT u OUTCOME_UNKNOWN también lleva upstream cuando Dataprev envió su propio código y mensaje.
Un comando del riel que responde OUTCOME_UNKNOWN está detenido. Dataprev respondió con un código que no es rechazo ni aceptación, no respondió a tiempo, o respondió sin su sobre. No lo envíes de nuevo, ni con una clave nueva ni con la misma, porque la misma clave responde RAIL_COMMAND_OUTCOME_UNRESOLVED. Lee GET /v1/consignado/rail-commands para ver el resultado. Una suspensão, reativação, o inclusión o exclusión de legado detenida sigue en outcome_unknown: confirma su efecto en el portal de Dataprev.
Una averbação de portabilidad lo responde mientras el gateway resuelve el contrato en Dataprev. Reenviar con cualquier clave es seguro, y no llega nada de nuevo a Dataprev hasta que el resultado se resuelva.
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_*, CEDED_CREDIT_*, SALDO_DEVEDOR_*, REGISTRO_B3_*, HELD_REPASSE_*, 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.
La liberación de repasse retenido,
POST /v1/consignado/reconciliation/held-repasses/{id}/release, responde estos códigos. En todo 409, el repasse sigue retenido en el panel.
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 tres 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, y OUTCOME_UNKNOWN lo lleva para un comando del riel detenido.
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.
En un comando del riel. El response_code de un comando en GET /v1/consignado/rail-commands también trae códigos que el propio gateway escribe, y empiezan con GW-. Los códigos de rechazo de abajo también llegan al reason_code de los hechos de rechazo.
GW-NAO-ENVIADO: la llamada no salió del gateway, así que no se ejecutó nada en Dataprev. El comando se cierra como rechazado. Envíalo de nuevo con una clave nueva.GW-BANCO-RECUSADO: el banco cerró el comando detenido como rechazado, según lo que muestra el portal de Dataprev.GW-M005-NAO-EXECUTADO: una lectura del contrato en Dataprev muestra que el comando no se ejecutó.
GW- marcan un comando que el gateway o el banco cerró como aceptado.
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.
