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:

Copy
Generic Error 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.