SEMP Error Handling
In the case of a failed request, an HTTP response code of 400, 401, or 500 is provided in the response. This value in itself does not provide any detail as to the reason for the failure, other than to blame the client (4xx) or server (5xx).
Further detail for the failure reason is provided by the returned error object, which includes a code, status, and description. The error code is a unique integer, which enumerates all possible error conditions. This value and its meaning will not change over time, although the set of error codes will grow, and old codes may be obsoleted. For readability, an accompanying short error status string and optional longer problem description are also returned. These strings MAY change over time; they should be used for the purpose of logging and debugging only.
The following table lists the most common codes you will see using SEMP:
| Error Code | Error Status | Description |
|---|---|---|
| 2 | FAIL | General error code used for a variety of failure conditions. The description text will explain further actions that developers can take to resolve this condition. |
| 6 | NOT_FOUND | The Object or Parent Object being accessed does not exist. |
| 11 | INVALID_PARMETER | An attribute or a parameter that is unexpected is in the object. |
| 14 | NOT_SUPPORTED | Indicates a request or an attribute that is not supported. |
| 27 | PARSE_ERROR | There was an error in the HTML format of the request or the JSON content of the payload. See the description for further details on how to resolve this formatting error. |
| 72 | UNAUTHORIZED | An incorrect access level user is trying to issue an request. |
| 89 | NOT_ALLOWED | A Delete request is prohibited due to an existing child object. |
| 228 | MISSING_PARAMETER | Some attributes in the request are required to be in certain combinations with other attributes. |
For a comprehensive list of current error codes, click the following link:
Handling Future Error Codes
Over time the SEMP API will continue to evolve and introduce new, more specific error codes to make it easier for developers to understand and use SEMP. Therefore developers should always maintain a default error handling condition which processes new codes for applications to be forward-compatible. Handling of the default condition should be similar to dealing with the generic fail condition.