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. Branch on code and on the status instead.
  • code – A stable identifier for the error. The tables below list the CLT-NNNN codes. Some operations answer a named code of their own, such as CURSOR_EXPIRED on the registration inventory sweep.
  • errors – Optional list of individual error details, each with a location, a message, and a value.
  • upstream – Dataprev’s own error, when the gateway relays one. It holds Dataprev’s code and message, and it survives the 5xx sanitization that clears detail. See Dataprev reason codes.

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.

410: Gone


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

413: Request entity too large


422: Unprocessable entity


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. Contract artifact downloads, contract corrections, disbursement confirmation, cessão registration, and bid submission answer 501 until your deployment enables them. The detail reads internal error, because Consignado sanitizes the detail on a 5xx response. Branch on the status.

503: Service unavailable


When Dataprev produced the fault, the response also carries upstream with Dataprev’s own code and message.

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 actually 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, both verbatim. The gateway bounds each field on the wire, so the member holds a code and a sentence rather than a response body. A 422 carries it for a deterministic rejection, and a 503 carries it for a retry-later fault. 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.