Errors

We like patterns. Unfortunately, not all of our possible errors fit into the HTTP status standard. Since we believe that numbers are not descriptive enough, we prefer to use strings as error codes. However, to be compatible with request libraries, we use HTTP status in the summary shown on the right.

Error code	Description
200	Everything went right
201	Everything went right. *Used in some specific cases
400	Your input is incorrect. We will send you a json explaining what went wrong.
401	Unauthorized function. Token fail
500	Something went wrong on our side. Our engineering team will be notified and act to fix the problem ASAP.

*In these cases there will be details in the call specification, indicating the return used.

Error object example

{
    "status": true,
    "message": "User Logged In Successfully",
    "token": "**********************7qyo03WAoP2fER5*****16"
}

{
  "status": false,
  "message": "Email & Password does not match with our record.",
  "errors" ["Password fail"]
}

The status field is only returned as true in case of success. The message field is a friendly message, while the errors field will contain one or more technical errors that will help in resolving the scenario.

The errors field is only returned mandatory in case of status = false, in successful operations it is not returned.