Operating Model:
Operating Model:

Errors

This section of the documentation lists and explains available error types and demonstrates how you can fix them.

How errors work

We expose all errors to our clients in a consistent manner. This means using both the standard HTTP Status Code and a consistent error response format. We have adopted the use of RFC 7807 for our error messages.

INFO

The content-type for all error messages is application/problem+json and not application/json as for all other responses.

Any response that returns an error HTTP Status Code back to the tenant has a JSON message formatted according to RFC 7807 in the response body.

Example error response

HTTP/1.1 401 Unauthorized
content-length: 174
content-type: application/problem+json
date: Mon, 11 Oct 2021 10:42:01 GMT
upvest-request-id: afcd3c2f-6965-4e1b-bb3e-87a3b481ce29

{
    "detail": "Signature is incorrect",
    "request_id": "afcd3c2f-6965-4e1b-bb3e-87a3b481ce29",
    "status": 401,
    "title": "Unauthorised",
    "type": "https://docs.upvest.co/guides/errors/unauthorised"
}

Error fields

  • detail: A human-readable description of the specific error.
  • instance: This optional key may be present, with a unique URI for the specific error; this will often point to an error log for that specific response.
  • request_id: Correlation ID for the original request.
  • status: Conveying the HTTP status code; this is so that all information is in one place, but also to correct for changes in the status code due to the usage of proxy servers.
  • title: A short, human-readable title for the general error type; the title should not change for given types.
  • type: URL to a document describing the error condition.

Was this page helpful?