[0] https://datatracker.ietf.org/doc/rfc7807/
* https://stripe.com/docs/api/errors
* https://developers.google.com/search-ads/v2/standard-error-r...
* https://cloud.google.com/blog/products/api-management/restfu...
I love the Stripe API documentation.
JSON-RPC is a bit more concrete: https://www.jsonrpc.org/specification#error_object But again what you put into data is up to you.
Response structure might also depend on the client (content negotiation)
I feel this is a mistake because in the backend you have absolutely no context about why the call was made, not to mention you aren't going to i18n the errors.
I'd suggest to return an error message designed for the developers using your API, and an error code (as RFC-7807 does) that is machine parsable to identify the type of error, so client applications can react to it and/or display a user friendly error message.