Skip to main content
Error format SILOC 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>. This URI repeats code, so it does not separate two statuses that share one code. A request that fails schema validation carries the RFC default about:blank instead.
  • title – The HTTP status text (for example, Not Found).
  • status – The HTTP status code.
  • detail – A human-readable explanation for this occurrence. A 500 response replaces 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. The code SILOC-0002 carries a 401, a 403, and a 503, each with its own action. A request that fails schema validation omits the field, 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.
The tables below list the codes SILOC returns, grouped by HTTP status.

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 Idempotency-Key, and never retry under a new one.