Skip to main content
Error format Lerian Consignado returns errors as RFC 9457 problem details with the application/problem+json media type:
Field definitions
  • type – A URI that identifies the error in the Lerian error catalog. Built as https://errors.lerian.studio/v1/<code>.
  • title – The HTTP status text (for example, Unprocessable Entity).
  • status – The HTTP status code.
  • detail – A human-readable explanation of this occurrence. On a 5xx response Consignado sanitizes the detail to internal error, so an internal cause stays out of the body. A 5xx code that names an upstream fault or an unknown outcome keeps a detail written for you, such as DATAPREV_TIMEOUT. Branch on code and on the status, not on the detail.
  • code – A stable identifier for the error. The tables below list the CLT-NNNN codes and the named codes that several operations share. Some operations answer codes of their own, such as CURSOR_EXPIRED on the registration inventory sweep. See Operation codes. A request that fails schema validation carries no code: it answers 422 with the detail validation failed, or 400 when the body cannot be parsed, and the errors list names each field.
  • errors – Optional list of individual error details, each with a location, a message, and a value.
  • instance – The trace ID of the request, when the gateway traced it. Quote it when you report a failure to Lerian.
  • upstream – The error an upstream system returned, which the gateway relays. It comes from Dataprev on a rail operation, and from the Streaming Hub on a subscription operation. It holds that system’s code and message, and it survives the 5xx sanitization that clears detail. See Dataprev reason codes.
  • refusal – On a bid refusal: the reason the gateway recorded for the bid, with its source, field, rule, and detail. A refusal from Dataprev also carries Dataprev’s code.

400: Bad request


401: Unauthorized


403: Forbidden


404: Not found


409: Conflict


CLT-0007 with the detail an identical request is already in flight marks a request the gateway has not finished. Retry that request under the same idempotency key. Command conflicts answer a named code in place of CLT-0007, so a client can tell them apart. Read code and detail together before you retry. These code spellings are part of the wire contract and do not change. After DATAPREV_CREDENTIAL_REQUIRED, upload the tenant’s Dataprev certificate, OAuth credentials, and requester code, then send the request again. After DATAPREV_CREDENTIAL_REJECTED, correct the tenant’s OAuth client credentials, then send a read again. A write may have parked its command: see Operate Lerian Consignado before you send it again.

410: Gone


The paginated registration inventory sweep issues a cursor with a limited retry window.

413: Request entity too large


An averbação body that carries the signed CCB, the evidence pack, the signature evidence, or data_hora_assinatura is refused. It answers 413 at 1 MiB or more, and 422 with the detail validation failed below that. Send them to POST /v1/consignado/contracts/{numero_contrato}/ccb-attachment once Dataprev accepts the averbação.

422: Unprocessable entity


Some refusals answer a named code in place of CLT-0006. Nothing reached Dataprev. The description says what to do next. The booking codes, from FIRST_DEDUCTION_BEFORE_COMPETENCIA to CONTRACT_NOT_BOOKABLE, apply only to a contract sent with the booking block. An averbação answers every booking code except FORMALIZATION_DEADLINE_EXCEEDED. Its documentation answers only DECLARED_DATES_OUT_OF_ORDER and FORMALIZATION_DEADLINE_EXCEEDED. A contract import with a booking answers every booking code except FIRST_DEDUCTION_BEFORE_COMPETENCIA. A command sent again under an idempotency key that an earlier request already spent can answer one of four named codes. The earlier request can already have reached Dataprev. Do not send the command again, under this key or a new one. Read the current state of the record the command changes. A portability auction response is the exception: its reference explains how a resend under a new key reveals the outcome.

429: Too many requests


Wait for the time the Retry-After header gives, then send the request again.

500: Internal server error


501: Not implemented


A 501 answers an operation your deployment has not enabled. The routes stay mounted, so the answer arrives per request rather than as a missing path. These operations answer 501 until your deployment enables them:
  • contract artifact downloads
  • contract corrections
  • bid submission
  • operations that reach Dataprev
Dataprev credential revocation answers 501 on a deployment whose credentials are static. The detail reads internal error, because Consignado sanitizes the detail on a 5xx response. Credential revocation is the exception: its detail says that the credentials are static. Branch on the status.

502: Bad gateway


503: Service unavailable


A DATAPREV_UNAVAILABLE or DATAPREV_TIMEOUT response also carries upstream when Dataprev sent its own code and message.

504: Gateway timeout


Operation codes


Some operations answer codes of their own, named after the operation: FUNDO_*, ORIGINADOR_*, CESSAO_*, CEDED_CREDIT_*, SALDO_DEVEDOR_*, REGISTRO_B3_*, and the cursor and filter codes of the list operations. The API reference enumerates every code in the code field of its error schema. The B3 instrument code operations, GET and PATCH /v1/consignado/contracts/{numero_contrato}/registro-b3, answer these codes.

Dataprev reason codes


Consignado relays Dataprev’s reason codes rather than mapping them onto codes of its own. That keeps a refusal readable against what Dataprev said. Read each reason code against Dataprev’s specification, not against this page. Dataprev can publish a code this page does not list, and the gateway still delivers it to you. They reach you in two places. On a refusal. The upstream member carries Dataprev’s own code and message. A refusal with several codes lists them comma-separated. The member holds Dataprev’s codes and sentences, bounded in length, rather than a response body. A 422 carries it for a deterministic rejection. DATAPREV_UNAVAILABLE and DATAPREV_TIMEOUT carry it for a retry-later fault. A Dataprev refusal of a command in upstream stays under its idempotency key. So does a bid refusal, whatever its source. The same key returns the same refusal, so send a corrected request under a new key. A bid refused with source dataprev also holds its solicitação, so any new bid for that solicitação answers BID_SOLICITACAO_TAKEN. A refusal the gateway makes on its own, with no upstream and no bid refusal member, does not keep the key, so a corrected request can go under the same key. An FGTS guarantee execution and a command that answers RAIL_COMMAND_* codes are the exception: they hold the key from before they call Dataprev. When a resend answers that an earlier request already holds the key, such as IDEMPOTENCY_KEY_REUSE or RAIL_COMMAND_PAYLOAD_MISMATCH, follow that code’s own instruction. On contract and margin responses. Several response fields pair a Dataprev reason code with Dataprev’s own label for it. A margin read publishes blockType and ineligibilityReason, which spell the pair code and description. A contract read publishes motivo_exclusao, origem_averbacao, origem_exclusao, portabilidade_situacao, and situacao_bloqueio_garantia, which spell it codigo and descricao. Each field holds a numeric code and the text Dataprev returned beside it. Treat the set as open. Map the reason codes your integration acts on, and pass the rest through with their labels, so a code you have not mapped yet stays readable to an operator.