Errors

 Table of Contents

Errors will be returned in a format containing:

  • Error Message ("errorMessage") describing the error
  • Unique Error ID ("errorId") that can be used in tandem with logging on the server to track down a more detailed stack trace
  • HTTP Error Code ("errorCode") for posterity
  • A timestamp of the time the error occurred ("timestamp")

For example, this is an error returned when supplying invalid JSON:

{
    "errorMessage": "Invalid JSON input: Property name must be a string literal: ERROR PARSING INPUT B - '{a:1}'",
    "errorId": "55fc57d5-3b53-4431-bee2-44f447747f41",
    "errorCode": 400,
    "timestamp": "2020-02-04T11:09:43.148+0000"
}

If set, the error will be returned in the content type specified in the Accept header of the request.

For example, if the request that produced the example above had the Accept header set to application/xml (to get the W3C XML representation of JSON), you would have received this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<errorMessage>
    <errorMessage>Invalid JSON input: Property name must be a string literal: ERROR PARSING INPUT B - '{a:1}'</errorMessage>
    <errorId>55fc57d5-3b53-4431-bee2-44f447747f41</errorId>
    <errorCode>400</errorCode>
    <timestamp>2020-02-04T11:09:43.148+0000</timestamp>
</errorMessage>

If no Accept header is set, it will return in JSON format.

#content .code