Skip to main content
Every failure returns the error envelope with a machine-readable code. That code is a kernel ResultCode, and each code maps to exactly one HTTP status. Branch on code, not on message.

The ResultCode → HTTP status map

OK is the success code (200); it never appears in an error body — the error code enum is the set of every ResultCode except OK.

How error responses are derived

Error responses are not hand-written per route; they are derived from the code→status map above, so the documented errors match what the server actually returns:
  • 400 and 500 are always possible.
  • 401 when the operation is authenticated.
  • 403 when the operation is scope-gated.
  • 404 when the path addresses a single resource (has an id param).
  • 409 for a conflict route.
  • 422 for a business-rule mutation.

Validation errors

A VALIDATION_FAILED body carries a fieldErrors array — one { field, message } per rejected field, where field is the dot-path of the offending field. Use it to map failures back onto a form:
Runtime validation failures are normalized into this exact envelope, identical to a domain use-case rejection — you handle both the same way.