Managing notification by using the Monitoring API

Fetch all user notifications

You can use the following cURL command to get information about all the notification channels:

curl -X GET <REST_API_ENDPOINT>/api/notificationChannels?from=<START_TIMESTAMP>&to=<END_TIMESTAMP> -H "Authorization: $AUTH_TOKEN" -H "IBMInstanceID: $GUID" -H "SysdigTeamID: $TEAM_ID" -H "content-type: application/json"

Where

• <REST_API_ENDPOINT>indicates the endpoint targetted by the REST API call. For more information, see Monitoring REST API endpoints. For example, the public endpoint for an instance that is available in us-south is the following: https://us-south.monitoring.cloud.ibm.com/api

• You can pass multiple headers by using -H.

  Authorization and IBMInstanceID are headers that are required for authentication.

  SysdigTeamID is optional. When you specify this header, you limit the request to the data and resources available for the team specified.

  To get an AUTH_TOKEN and the GUID see, Headers for IAM Tokens.

• to and from are query parameters that you must define to configure the period of time for which you want information on the notifications.

For more information about the response format, see notification schema.

Fetch specific user notification

You can use the following cURL command to get information about a notification channel:

curl -X GET <REST_API_ENDPOINT>/api/notificationChannels/<NOTIFICATION_ID> -H "Authorization: $AUTH_TOKEN" -H "IBMInstanceID: $GUID" -H "SysdigTeamID: $TEAM_ID" -H "content-type: application/json"

Where

• <REST_API_ENDPOINT>indicates the endpoint targetted by the REST API call. For more information, see Monitoring REST API endpoints. For example, the public endpoint for an instance that is available in us-south is the following: https://us-south.monitoring.cloud.ibm.com/api

• You can pass multiple headers by using -H.

  Authorization and IBMInstanceID are headers that are required for authentication.

  SysdigTeamID is optional. When you specify this header, you limit the request to the data and resources available for the team specified.

  To get an AUTH_TOKEN and the GUID see, Headers for IAM Tokens.

• <NOTIFICATION_ID> defines the ID of the notification that you want to modify.

For example, the response body for an email notification channel looks as follows:

{
  "notificationChannel": {
    "id": 20,
    "version": 1,
    "createdOn": 1466023669000,
    "modifiedOn": 1466023669000,
    "type": "EMAIL",
    "enabled": true,
    "name": "emailChannel",
    "options": {
      "emailRecipients": [
        "abc@xyz.com"
      ],
      "notifyOnOk": false
    }
  }
}

Create a notification

You can use the following cURL command to create an notification:

curl -X POST <REST_API_ENDPOINT>/api/notificationChannels -H "Authorization: $AUTH_TOKEN" -H "IBMInstanceID: $GUID" -H "SysdigTeamID: $TEAM_ID" -H "content-type: application/json" -d @notification.json

Where

• <REST_API_ENDPOINT>indicates the endpoint targetted by the REST API call. For more information, see Monitoring REST API endpoints. For example, the public endpoint for an instance that is available in us-south is the following: https://us-south.monitoring.cloud.ibm.com/api

• You can pass multiple headers by using -H.

  Authorization and IBMInstanceID are headers that are required for authentication.

  SysdigTeamID is optional. When you specify this header, you limit the request to the data and resources available for the team specified.

  To get an AUTH_TOKEN and the GUID see, Headers for IAM Tokens.

• You can pass data to create the notification in the notification.json file by using -d.

  Valid types are EMAIL, PAGER_DUTY, SLACK, and VICTOROPS.

The following sample shows the request body parameters that you can set to create an notification:

{
  "notificationChannel": {
      "type": "SLACK",
      "enabled": true,
      "name": "my-slack-channel",
      "options": {
        "notifyOnOk": true,
        "url": "https://hooks.slack.com/services/xxx",
        "channel": "myslack"
        "notifyOnResolve": true,
      }
    }
  }

Delete a notification

To delete an existing notification, you need the ID of that notification.

You can use the following cURL command to delete a notification:

curl -X DELETE <REST_API_ENDPOINT>/api/notificationChannels/<NOTIFICATION_ID> -H "Authorization: $AUTH_TOKEN" -H "IBMInstanceID: $GUID" -H "SysdigTeamID: $TEAM_ID" -H "content-type: application/json"

Where

• <REST_API_ENDPOINT>indicates the endpoint targetted by the REST API call. For more information, see Monitoring REST API endpoints. For example, the public endpoint for an instance that is available in us-south is the following: https://us-south.monitoring.cloud.ibm.com/api

• You can pass multiple headers by using -H.

  Authorization and IBMInstanceID are headers that are required for authentication.

  SysdigTeamID is optional. When you specify this header, you limit the request to the data and resources available for the team specified.

  To get an AUTH_TOKEN and the GUID see, Headers for IAM Tokens.

• <NOTIFICATION_ID> defines the ID of the notification that you want to modify.

Update a notification

To update an existing notification, you need the ID of that notification.

You can use the following cURL command to update an notification:

curl -X PUT <REST_API_ENDPOINT>/api/notificationChannels/<NOTIFICATION_ID> -H "Authorization: $AUTH_TOKEN" -H "IBMInstanceID: $GUID" -H "SysdigTeamID: $TEAM_ID" -H "content-type: application/json" -d @notification.json

Where

• <REST_API_ENDPOINT>indicates the endpoint targetted by the REST API call. For more information, see Monitoring REST API endpoints. For example, the public endpoint for an instance that is available in us-south is the following: https://us-south.monitoring.cloud.ibm.com/api

• You can pass multiple headers by using -H.

  Authorization and IBMInstanceID are headers that are required for authentication.

  SysdigTeamID is optional. When you specify this header, you limit the request to the data and resources available for the team specified.

  To get an AUTH_TOKEN and the GUID see, Headers for IAM Tokens.

• <NOTIFICATION_ID> defines the ID of the notification that you want to modify.

• You can pass data to create the notification in the notification.json file by using -d.

The following sample shows the request body parameters that you can set to update an notification:

{
  "notificationChannel": {
    "id": 9,
    "version": 2,
    "type": "WEBHOOK",
    "enabled": true,
    "name": "test-tip-webhook",
    "options": {
      "notifyOnOk": false,
      "url": "https://test-tip.endpoint.com",
      "notifyOnResolve": true
    }
  }
}

Request body parameters: All the response body parameters specified in GET notification channel except:

• createdOn
• modifiedOn

Note: Notification version can get through response body of notificationChannels API. User can also add customHeaders & customData to notfications based on their requirements.

Notifications schema: Request body

See schema for getting information about 1 or more notifications channels:

{
  "notificationChannel": {
    "id": 20,
    "version": 1,
    "type": "",
    "enabled": true,
    "name": "",
    "options": {
      "notifyOnOk": false,
      "notifyOnResolve": true,
      "resolveOnOk": true,
      "channel": "",
      "emailRecipients": "",
      "url" : "",
      "apiKey": "",
      "routingKey": "",
      "account": "",
      "serviceKey": "",
      "serviceName": ""
    }
  }
}

Sww schema when you create, update, or delete a notification channel:

{
  "notificationChannel": {
    "id": 20,
    "version": 1,
    "type": "",
    "enabled": true,
    "name": "",
    "options": {
      "notifyOnOk": false,
      "notifyOnResolve": true,
      "resolveOnOk": true,
      "channel": "",
      "emailRecipients": "",
      "url" : "",
      "apiKey": "",
      "routingKey": "",
      "account": "",
      "serviceKey": "",
      "serviceName": ""
    }
  }
}

Notifications schema: Response body

{
  "notificationChannel": {
    "id": 20,
    "version": 1,
    "createdOn": 1466023669000,
    "modifiedOn": 1466023669000,
    "type": "",
    "enabled": true,
    "name": "",
    "options": {
      "notifyOnOk": false,
      "notifyOnResolve": true,
      "resolveOnOk": true,
      "channel": "",
      "emailRecipients": "",
      "url" : "",
      "apiKey": "",
      "routingKey": "",
      "account": "",
      "serviceKey": "",
      "serviceName": ""
    }
  }
}

Body parameters

Options (json)

Options are different per type of notification channel.

The following JSON shows the schema model:

"options": {
      "notifyOnOk": false,
      "notifyOnResolve": true,
      "resolveOnOk": true,
      "channel": "",
      "emailRecipients": "",
      "url" : "",
      "apiKey": "",
      "routingKey": "",
      "account": "",
      "serviceKey": "",
      "serviceName": ""
    }

Table 3. Types of notification channels

Option	EMAIL	PAGER_DUTY	SLACK	VICTOROPS	WEBHOOK	OPSGENIE
name
notifyOnOk
notifyOnResolve
resolveOnOk
emailRecipients
url
apiKey
routingKey
account
serviceKey
serviceName

apiKey (string)

VictorOps's API key. You must get this key from your VictorOps integration settings page.

channel (string)

Name of the channel.

emailRecipients (string)

List of email addresses.

notifyOnOk (boolean)

Flag that indicates the status to send a notification when the notification state changes from ACTIVE to OK and the notification is manually acknowledged by a user.

Set to true to send a notification.

Query parameters