Skip to main content
Error format SILOC returns errors as RFC 9457 problem details:
Field definitions
  • type – A URI that identifies the error in the Lerian error catalog, built as https://errors.lerian.studio/v1/<code>. This URI repeats code, so it does not separate two statuses that share one code.
  • title – The HTTP status text (for example, Not Found).
  • status – The HTTP status code.
  • detail – A human-readable explanation for this occurrence. A 500, a SILOC-0023, and a SILOC-0024 replace the text with internal error, so the internal cause stays inside the rail. The text varies per occurrence, and a 403 can carry the message the authorization service reported. Do not branch on it.
  • code – The stable, machine-readable code (SILOC-NNNN). Dispatch on the pair of status and code, not on code alone. One code can appear under more than one status, and each status needs a different action. For example, SILOC-0001 is a 503 from the authorization gate and a 422 from a card operation. A request that fails schema validation carries SILOC-0022, and errors names the fields at fault.
  • errors – An optional list of field-level details, each with the location it read, a message, and the value found there. A refusal from the authorization or idempotency gate carries an empty violations list instead.
The tables below list the codes SILOC returns, grouped by HTTP status.

400, 413, 415: Request body refused


401: Unidentified caller


403: Refused caller


404: Not found


409: Conflicts


422: Validation errors


500: Server errors


503: Rail cannot answer


A 503 that carries SILOC-0002 does not tell you the command was rejected. The rail answers with it both before the command runs and after it commits, so the command may already have taken effect. Reconcile the original request first. When you do retry, send the same X-Idempotency, and never retry under a new one.