Skip to main content
Use IBM SevOne NPM 8.x Webhook Definition Manager to send policy alert triggers and clears to Flashduty On-call. SevOne has no fixed webhook payload: you write the request body as a template, so this page gives the JSON template to paste and Flashduty parses exactly that template. Each SevOne alert maps to one Flashduty alert: it is created when the policy triggers, merges on repeated triggers, and closes when the policy clears.

In Flashduty On-call

You can get the integration push URL in either of the following ways.

Use a dedicated integration

  1. In the Flashduty console, go to Channels and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add integration
  3. Select IBM SevOne NPM and click Save
  4. Open the generated integration card and copy the Push URL

Use a shared integration

  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select IBM SevOne NPM and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routing after creation
  4. Click Save and copy the generated Push URL

Configure SevOne NPM

Create two Webhook Definitions: one sent when an alert triggers, one sent when it clears.
1

Create the trigger webhook in SevOne NMS

Where: SevOne NMS › Events › Configuration › Webhook Definition Manager
Click Test Definition to check that the request can be sent, then click Save. The documentation does not describe the request body that Test Definition sends, and it usually has no valid alert_id and event, so it only proves connectivity and does not prove that an alert can be created. Verify with a real alert (see the last step).
2

Create the clear webhook in SevOne NMS

Where: SevOne NMS › Events › Configuration › Webhook Definition ManagerCreate a second definition the same way. All fields match the previous step except these two:
3

Assign the webhooks to policies

Where: SevOne NMS › Events › Configuration › Policy Browser › Assign WebhooksAssign the clear webhook to the same policies, otherwise Flashduty alerts do not recover automatically.
4

Trigger a real alert and confirm

Where: SevOne NMS › Events › AlertsLet a policy trigger and confirm Flashduty shows an active alert. Then let it clear (the condition recovers, or acknowledge it manually under Events → Alerts) and confirm the alert recovers.Back in Flashduty, the integration shows Latest event time, which means the setup works.
  • Content Type must be application/json. SevOne escapes variables according to the Content Type, so other types can produce JSON that cannot be parsed.
  • event must be trigger in the trigger template and clear in the clear template. Flashduty rejects other values.
  • The push URL carries integration_key, so no authentication header is needed.

Payload

Each field is the substitution of one SevOne variable (see IBM’s Webhook Definition Manager): SevOne outputs n/a for a variable a policy type does not support (for example $pluginName on flow policies). Flashduty ignores n/a.

Alert key

Flashduty uses alert_id ($alertId, described by IBM as “The id of the triggered alert”) as the Alert Key. Repeated triggers and the clear of one SevOne alert carry the same alert_id, so they land on one Flashduty alert. Changing the policy name, severity or message does not change the Alert Key. If alert_id is empty, n/a, or still the unsubstituted $alertId, Flashduty returns a parameter error.

Status and severity

$alertState is the policy severity. A clear event keeps the alert’s severity and sets the status to recovered.

FAQ

IBM documents only that Test Definition returns the status code, response header and body; it does not document the test body. If the test request carries a valid alert_id and event, it creates or closes an alert like a real notification; without them Flashduty returns a parameter error. Close any alert created by a test manually.
Alerts arrive, but Flashduty alerts do not recover automatically. Enable auto-close on timeout in the integration or channel, or add the clear webhook.
No. Every trigger of the same SevOne alert has the same alert_id and merges into one Flashduty alert.
The templates on this page are for the Policy type. Trap definitions use a different variable set and are out of scope for this integration.

Troubleshooting

  • SevOne cannot deliver: check that Destination URL is the complete push URL; for a self-signed TLS certificate, check Allow insecure webhook connection, and use a certificate with a SAN rather than only a Common Name
  • Flashduty returns a parameter error: check that Content Type is application/json, event is trigger or clear, and alert_id has a value
  • Alert does not recover: check that the clear webhook is assigned to the same policy with Clear checked