This document contains a list of errors that the API methods can return.
Errors can be divided into six categories:
Fatal system errors, these should not appear during normal API operations.
A fatal system error. This shouldn't have happened. Please contact the Monit24.pl support.
There was an error while loading the module, caused by an error in the module itself. Please inform the Monit24.pl support if this error occurs.
The request you sent had incorrect format.
This means that you failed to conform to the request format described in README,
for example didn't specify the module that you want to use.
These errors do not include method input validation (data is not checked here)
This error indicates that your request contained an incorrectly formatted JSON content.
You specified a non-existent module in your request
The module you selected doesn't provide the desired method
The JSON request doesn't contain a JSON object
This error occurs when the format of your request is incorrect.
These errors indicate problems with API version. See Versions for more information.
You specified an API version that you want to use, but this API has a different version.
Problems with authentication. The most common is incorrect login or password or expired session.
You supplied incorrect autentication credentials (login and/or password).
Your supplied an invalid session ID or your session has expired.
This error occurs when you try to invoke an API method that you are not allowed to invoke. Please contact the Monit24.pl support to have the method unblocked.
User authentication is required - you need to authenticate to use this method.
Account login required - you need to authenticate to an account to use this method.
You are not allowed to call this method due to your user type (for example you are a regular user and try to call a distributor's method)
You cannot change a password when authenticating with a session (for security reasons).
The method input (the data element of the request) is incorrect for the method.
It includes only the formal validation that could be as well performed by the API client based on the documentation and specification (JSON/WSDL).
For example,
it includes checking that a service id is an unsigned integer,
but not that this service is accessible by the user.
This error occurs when you call an API method with incorrect data. Please refer to the documentation and/or the WSDL files to see what arguments are expected by each method. The SOAP Fault detail field may contain additional information about which argument caused the error.
Any errors that cannot be predicted before calling the method. Examples include trying to access inexistent objects or dynamic validations based on other object types (a good example is the service features array - validations are dependent on the service type).
You tried to use a filter with an argument of different type than the field's type.
You supplied an incorrect service id (the service with this id doesn't exist or is not owned by you).
The service type is not allowed for your account or does not exist.
You have reached the services limit for your account.
Service features are incorrect. Details contain more information about what exactly went wrong.
The checks interval you are trying to set for a service is too low for your account.
You supplied an incorrect group id (there is no group with this id or it is not owned by you).
You supplied less than 2 monitoring stations for a group.
You tried to assign more monitoring stations to a group than allowed by your account's limits
The monitoring station you tried to use does not exist or you specified a station ID twice.
You tried to delete the default group for your account, which is not allowed.
The notification channel you are trying to use is not allowed for your account.
You supplied an incorrect notification address ID (notification address with this ID does not exist)
The notification address is incorrect for selected notification channel (e.g. incorrect e-mail address for "email_long")
SMS numbers limit for your account has been exceeded.
You supplied an incorrect report address ID (report address with this ID does not exist)
You supplied an incorrect service suspension ID (service suspension with this ID does not exist)
You tried to create a service suspension with start timestamp set after end timestamp.
The service feature you tried to access does not exist.
Cannot delete a service feature that is required for the service.
The service type feature does not exist or you are not allowed to have services of this type.
The package you are trying to read does not exist.
The user does not exist.
The login you are trying to use already exists in the system.
The distributor does not exist.
The account you are trying to use does not exist or you are not allowed to use it.
The account you are trying to activate has already been activated.
The account you are trying to block is already blocked.
The account you are trying to unblock is already unblocked.
The account has not been activated yet.
The service check (identified by service ID + location ID + iteration ID) was not found.
The error type was not found.
The mobile notification was not found.
The error data will be returned in the response's error field when using JSON or in SOAP Fault's details when using SOAP.
Error data contains three fields:
The error category.
It will be one of the categories described above (system,
auth,
version,
...).
An error message.
It contains a human-readable description of what went wrong in the language specified in the request's lang attribute.
An array of detailed error information, with pointers to elements of your request that caused the error. You can think of them like a HTML form validation errors array. Each element of this array contains fields:
A numeric error code, one of the listed above.
A human-readable description of the problem (in the selected language).
A pointer to the element of your request that caused the error. This is a string containing the path of hash keys or array indices in the request from top to bottom, separated by "/"s. The example below should make it clear.
Assume that we want to create a http service but our package does not allow checks every 10 minutes and we have reached the services limit and we don't have group with id 123:
{
"module":"Service",
"method":"Create",
"auth":{"login":"monit_api_test_user","password":"my_passwoRd"},
"data":{
"name":"a new service",
"interval":600,
"type_id":1,
"url":"monit24.pl",
"group_id":123
}
}
The API will complain:
{
"auth":{},
"version":"2.0.0",
"error":{
"blame":[
{
"path":"data/group_id",
"message":"Group not found",
"code":1000201
},
{
"path":"data",
"message":"Services limit for your account has been reached",
"code":1000104
},
{
"path":"data/interval",
"message":"Too low interval. Your account limits allow you to check services not more frequently than every 900 seconds",
"code":1000106
}
],
"type":"data_validation",
"message":"Input data validation error"
},
"data":null
}
Note that sometimes some blames can be dependent on others. For example, service features will not be validated if you specify an inexistent type for your service, because the features are type-dependent - API will return an error before even trying any features validation.
An example that shows the path attribute for arrays - trying to modify the port service feature (it has to be an integer):
{
"module":"Service",
"method":"Update",
"auth":{"login":"monit_api_test_user","password":"my_passwoRd"},
"data":{
"id":278174,
"features":[
{
"id":"port",
"value":"this_is_not_a_number"
}
]
}
}
The response:
{
"auth":{},
"version":"2.0.0",
"error":{
"blame":[
{
"path":"data/features/0/value",
"message":"Incorrect value: integer required",
"code":1000105
}
],
"type":"data_validation",
"message":"Input data validation error"
},
"data":null
}