Errors

Format

Errors will be returned in a format containing:

ErrorMessage - the message of the error
ErrorId - a unique ID identifying this particular error (to correspond to the full error logged on the server)
ErrorCode - the HTTP response code
timestamp - date and time of error in ISO-8601 format

For example, this is the error returned when supplying inputs with different root elements:

XML

CODE

<Error>
    <ErrorMessage>Problem processing anna - The element type "a" must be terminated by the matching end-tag "</a>".</ErrorMessage>
    <ErrorId>94cf4345-956a-4644-8214-02c1e09406d6</ErrorId>
    <ErrorCode>400</ErrorCode>
    <timestamp>2019-04-12T10:31:54.766+0000</timestamp>
</Error>

JSON

CODE

{
    "ErrorMessage": "Problem processing anna - The element type \"a\" must be terminated by the matching end-tag \"</a>\".",
    "ErrorId": "94cf4345-956a-4644-8214-02c1e09406d6",
    "ErrorCode": 400,
    "timestamp": "2019-04-12T10:31:54.766+0000"
}

Content Type

If set, the error will be returned in the content type specified in the Accept header of the request. This is mainly useful for async requests - where the response from the merge request does not normally contain any content.

For example if there was an error getting a Job's information and you set Accept to application/json, it will be returned in JSON format.

If no Accept header is set, and you posted XML or JSON formatted requests, it will return in the content type of your inputs.

If neither of those previous conditions are set (e.g. no Accept header and posted a comparison using multipart/form-data) it will fallback to XML format.

Stack Trace

There is an additional StackTrace element showing the full stack trace of the exception. This is by default disabled, and can be enabled if you have the correct license at start time. Contact DeltaXML if this feature would be useful (e.g. running on-premise).