The error responses of the fuga-backend API are in the RFC 9457 format "Problem Details for HTTP APIs" (application/problem+json).
1. General errors
{
"type": "about:blank",
"title": "Bad Request",
"status": 400,
"detail": "...",
"instance": "/the/called/path"
}- Use
detailfor the human-readable error description. - Use
statusas an integer, for example 400, or the HTTP status line. - The
titlefield contains the standard HTTP status description, for example Not Found, Bad Request, Unauthorized, Service Unavailable or Bad Gateway. - The
instancefield contains the path of the request that caused the error. - The
typefield is set toabout:blank.
2. Validation errors
{
"type": "about:blank",
"title": "Bad Request",
"status": 400,
"detail": "Validation failed",
"instance": "/api/...",
"errors": [
{ "field": "amount", "message": "positive" }
]
}- The
errorsarray sits at the top level, with the structure (field/message). - Do check that your client accepts the new Content-Type and the full response body.
3. Framework / transport errors
These errors also use the Problem Details format described above.
4. Generic detail messages for data and system errors
For certain errors — such as data/database errors and internal processing errors — detail now contains a generic, safe message instead of internal technical details such as SQL or database errors.
This is a deliberate security measure: technical details are logged server-side only. Do not rely on specific internal error texts in the response body. Use status and title for error handling.
5. Content-Type
The Content-Type of error responses becomes:
application/problem+json
This is still JSON. Note the +json suffix. If your client strictly checks for Content-Type: application/json, please adjust it so that application/problem+json is also accepted.