Skip to main content
Error format Lerian SLC 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 Conflict or Unprocessable Entity. It comes from the status, not from the name of the error.
  • status – The HTTP status code, repeated from the response status line.
  • detail – An explanation specific to this occurrence. A response with status 500 or above carries the fixed text internal error, so branch on code instead of parsing this field.
  • code – The stable machine identifier, in the form SLC-NNNN. Branch on this field.
  • errors – A list of per-field details, each with a location, a message, and the offending value. A schema validation failure lists one entry per field.

Platform and request errors


These codes can arrive from any endpoint. Each one describes the request, the credential, or the availability of the service rather than the settlement operation itself.

Settlement operation errors


These codes come from the operations domain. They describe the settlement instruction you submitted, the original operation a cancellation targets, or the answer a reconcile received from the counterparty.

Nuclea rejection codes


Nuclea, the clearing house that operates the SLC, answers a submission or a return file with its own business error codes, in the form ESLCNNNN. Lerian SLC records them against the operation and hands them back unchanged. The operation detail response carries eslcErrors, an array of the recorded codes that is empty when the operation has none, and lastError, the recorded codes joined into one string. Each code value arrives verbatim from the network, so read it as Nuclea vocabulary rather than a Lerian code. Nuclea defines 85 of these codes in its SLC layout manual. The table below covers the ones that change what you do next.
Four of these codes reach you on a synchronous refusal of a file submission: ESLC0119, ESLC0123, ESLC0140, and ESLC0161. They arrive on the operation.forward_rejected event, in rejectionCode, rather than on the return file. Each one is a registration or enrolment condition that applies to every file the participant sends, and a registration change at Nuclea clears it. The file itself needs no edit.
The remaining codes The rest of the catalog describes the submitted record or the participant registration. The largest families are:
  • Field domain and format – A value sits outside the domain the layout permits, or a segment carries the wrong format. Currency codes, person types, arrangement institutors, and occurrence codes appear here.
  • Registration and enrolment – A CNPJ, an ISPB, or a participant relationship differs from what Nuclea holds for the acquirer.
  • Duplicate control numbers – A control number or a file name repeats one Nuclea already registered.
  • Dates and reporting periods – A payment date, a reference date, or a report range sits outside what the product type permits.
  • Record state and occurrence codes – The occurrence code does not suit the current state of the record, such as a settled record or a cancelled one.
  • Return periods – The record sits inside a return period, and Nuclea names the file type that carries the correction.
  • Limits and volumes – A payment amount, a file count, or a record count sits above the accepted maximum.
A code from any of these families reaches you on the return file, through eslcErrors on the operation. Quote the code when you raise the case with Nuclea, because it is the identifier Nuclea support works from.