2xx HTTP status code and a JSON body that describes what went wrong. Error bodies follow RFC 9457 — Problem Details for HTTP APIs and are served with the application/problem+json content type.
Example error response
Fields
A problem details object may also carry extension members — additional fields specific to a problem type, as allowed by Section 3.2 of the RFC. Ignore any field you do not recognize instead of failing to parse the response.
Handling errors
- Branch on
statusandtype. The HTTP status code tells you the class of failure (a4xxmeans the request needs to change, a5xxmeans the request can be retried);typetells you exactly which problem occurred. - Do not parse
detailortitle. Both are meant for humans — the wording can change at any time without being a breaking change. Show them in logs and error messages, but never key application logic off them. - Accept
application/problem+json. Some HTTP clients only deserializeapplication/jsonby default and will hand you an unparsed string otherwise. - Log
instanceand the request path. Include them when you contact support so we can trace the exact call.
Requests to a path that does not exist are rejected before reaching the API’s error handling and return a plain If you see this shape, check the method and path against the endpoint reference.
application/json body instead of problem details:Getting an error you cannot explain? Contact us at support-wave@bemobi.com.