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.


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": ""

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: Transmission of the HTTP status code so that all information can be found in one place, but also to correct changes in the status code due to the use 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?