Error handling
Botize can gracefully handle any standard HTTP error code that receives from your server.
These include 400 for bad verb or invalid/malformed request, 401 for bad authentication data, 404 for non existing resource requested, or 500 for internal server error.
Aside from these “low-level” errors, requests for processing triggers and actions must return an error code as part of the returned data. These “high-level” errors should be used when the request sent by Botize is perfectly valid and your server is working properly, but the request cannot be fulfilled for some reason (typically, an external service is down or is rejecting requests). The HTTP status code in this case should always be 200.
The possible values for these “high-level” error codes are not defined by Botize (other than 0 for success), but by yourself as the application developer. However, these codes should be inside of a set of predefined ranges that define a severity level and help Botize to decide whether the task should be disabled until you (or the end user) check what is happening and correct whatever is causing the error if at all possible. See the process_trigger command description for more details.
All errors produced by your applications are logged by Botize, so that the end user can check them in the Botize control panel.
These include 400 for bad verb or invalid/malformed request, 401 for bad authentication data, 404 for non existing resource requested, or 500 for internal server error.
Aside from these “low-level” errors, requests for processing triggers and actions must return an error code as part of the returned data. These “high-level” errors should be used when the request sent by Botize is perfectly valid and your server is working properly, but the request cannot be fulfilled for some reason (typically, an external service is down or is rejecting requests). The HTTP status code in this case should always be 200.
The possible values for these “high-level” error codes are not defined by Botize (other than 0 for success), but by yourself as the application developer. However, these codes should be inside of a set of predefined ranges that define a severity level and help Botize to decide whether the task should be disabled until you (or the end user) check what is happening and correct whatever is causing the error if at all possible. See the process_trigger command description for more details.
All errors produced by your applications are logged by Botize, so that the end user can check them in the Botize control panel.