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 and a SILOC-0023 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-0022 is a 400 for a body that is not valid JSON and a 422 for a value that breaks a domain rule. 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 means the command did not run. Retry with the same X-Idempotency. When only the receipt of a command that ran is lost, the rail returns the command’s own answer with the X-Idempotency-Fenced header. When the answer of an earlier request cannot be replayed, the rail answers 409 SILOC-0009. Reconcile the original request, and never retry it under a new key.