Alerts endpoint

A POST to /api/open/alerts/close request lets you to close a group of alerts passed as a json list of ids in the body of the request. You must also pass as parameter the close_action field containing delete_rules or learn_rules in case you want to close alerts as security or as change.

Requirements and Restrictions

1. The authenticated user must be in a group having admin role.
2. The input data must be a JavaScript Object Notation (JSON) dictionary containing a ids key whose value must be an array of alert 'id' and a 'close_action' constant field.
3. In case the request body does not adhere to the format described above the call returns a 422 error.
4. In case the request is well formed, the result will contain the id of the job in charge of the task. You can monitor the status of the job via the alerts/close/status/:id application programming interface (API).

         {
            "ids": ["uuid"],
            "close_action": "learn_rules"
         }
    

A GET to /api/open/alerts/close/status/:id request lets you to get the status of a job in charge of a close alerts task.

Requirements and Restrictions

1. The authenticated user must be in a group having admin role.
2. As last parameter of the path you need to specify the id of the job returned by the alerts/close API.
3. The result will contain the status of the job, which can have one of the following values: SUCCESS, PENDING or FAIL
4. In case of FAIL status, the error field will report the error reason.

A POST to /api/open/alerts/ack request lets you to ack/un-ack a group of alerts passed as a json list of id/ack_status pairs in the body of the request.

Requirements and Restrictions

1. The authenticated user must be in a group having admin role.
2. The input data must be a JSON dictionary containing a data key whose value should be an array of pairs with an alert 'id' and an 'ack' field. Ack can be true or false.
3. In case the request body does not adhere to the format described above the call returns a 422 error.
4. In case the request is well formed, the result will contain the id of the job in charge of the task. You can monitor the status of the job via the alerts/ack/status/:id API.

                {
                   "data": [
                       {
                           "id": "uuid",
                           "ack": true
                       }
                   ]
               }
          

A GET to /api/open/alerts/ack/status/:id request lets you to get the status of a job in charge of a ack/un-ack alerts task.

Requirements and Restrictions

1. The authenticated user must be in a group having admin role.
2. As last parameter of the path you need to specify the id of the job returned by the alerts/ack API.
3. The result will contain the status of the job, which can have one of the following values: SUCCESS, PENDING or FAIL
4. In case of FAIL status, the error field will report the error reason.

A GET to /api/open/alerts/all request lets you to get the IDs of alerts matching a condition. You can specify a filter query in the query parameter and an additional parameter named has_trace to get the status of the corresponding trace.

Requirements and Restrictions

1. The authenticated user has to belong to a group having admin role or with Alerts section enabled.
2. The query parameter should be in Nozomi Networks Query Language format, where the table name is implicit, i.e. alerts.
3. The has_trace parameter type is boolean.
4. If no alert matches the specified conditions, a 404 error will be returned.

A GET to /api/open/alerts/:id/trace request lets you to get a file containing the trace of the alert, whose id is specified as a parameter.

Requirements and Restrictions

1. The authenticated user has to belong to a group having admin role or with Alerts section enabled.
2. The alert id should be passed in the path.
3. If the alert does not exist, a 422 error is returned.
4. In case there is no trace for the specified alert, a 404 error will be returned.

A POST to /api/open/alerts/import request lets you to import alerts by passing attributes in JSON format in the body of the request.

Requirements and Restrictions

1. The authenticated user must be in a group having admin role or with Alerts section enabled.
2. The alerts information should be provided in a JSON array named alerts.
3. In case the request body does not adhere to the format described above the call returns a 422 error.
4. In case the request is well formed, the result can contain the validation outcome for errors regarding mandatory fields and warnings for fields that are potentially missing.
5. If one or more alerts are passing the validation, the result will also contain the id of the job in charge of importing the alerts. You can monitor the status of the job via the alerts/import-status API.

A GET to /api/open/alerts/import-status request lets you to get the status of a job in charge of importing alerts.

Requirements and Restrictions

1. The authenticated user must be in a group having admin role.
2. You need to specify the id of the job returned by the alerts/import API in the id parameter.
3. The result will contain the status of the job, which can have one of the following values: SUCCESS, PENDING or FAIL
4. In case of FAIL status, the error field will report the error reason.

A PATCH to /api/open/alerts/:id lets you to update the alert's note.

Requirements and Restrictions

1. The authenticated user must be in a group having admin role or with Allow alert ack and edit enabled.
2. The note must be passed as a query parameter or in the JSON body.
3. The result will contain the JSON representation of the Alert updated.