Generic Statuses and Errors
When an API method runs, one of the following HTTP response status codes is returned:
- 200 - Indicates successful call; returned string can be either ok or error.
- 401 - Indicates unsuccessful call; not authorized.
- 404 - Indicates unsuccessful call; not found by ID.
- 500 - Indicates internal error associated with SessionM.
Here is an example:
{
"status" : "error",
"errors" :
{
"code" : "requires_registered_user"
}
}
When the string returned with a 200-level status code is ok, the transaction did process. But, if the string returned is error, you need to discover what type of error occurred.
Consider the generic error example shown in the frame right-hand frame. Returned errors can be either method-specific or generic, which is the case for the error above. Any method-specific errors are documented in their associated API document. However, responses that return generic errors may contain a message from the platform indicating any of the following conditions:
Code | Reason |
---|---|
INTERNAL_SERVER_ERROR | Unexpected SessionM server error occurred. |
HTTPS_ONLY | HTTPS protocol is required. |
INVALID_AUTH_TOKEN | Token could not be decrypted; or token has expired. |
USER_NOT_FOUND | Customer ID or external customer ID not located in the system. |
INVALID_API_KEY | Wrong API key passed in. |
REQUIRES_REGISTERED_USER | Similar to USER_NOT_FOUND. |
MISSING_DATA | Required parameters not passed in. |
VALIDATION | This catch-all validation error is returned when there is no specific error code. |
ACCESS_DENIED | Authentication credentials passed in were invalid. |
NOT_AVAILABLE | Object was found but is unavailable. For example, a campaign not being targeted to a requesting customer. |
NOT_FOUND | Object does not exist. |
ARGUMENT_ERROR | Unexpected type or format parameter. |
For information on responses that return object-specific errors, see the object's dedicated API.
Note: When developing code that integrates with the SessionM platform, organizations can expect that error codes will not change. This principle ensures that development teams can utilize these error codes to create and communicate error messages that make sense for their implementation, or their customers. Alternatively, it's worth noting that the SessionM messages provided with the codes are available.