> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ntopng alert integration

> Send ntopng host, interface, and flow alert engage and release events to Flashduty On-call through a webhook endpoint.

Use an ntopng Webhook endpoint to send ntopng alerts to Flashduty On-call. For hosts, interfaces, networks, and other entities, ntopng first sends `engage` (triggered) and, once the condition clears, `release`. Flashduty links the two messages with one Alert Key: engage creates the alert and release recovers it. Flow alerts are sent once and never released.

<div className="hide">
  ## In Flashduty On-call

  ***

  Create either a dedicated or shared **ntopng** alert integration and copy its complete Push URL.

  ### Dedicated integration

  1. In the Flashduty console, select **Channels** and open a channel
  2. Go to **Settings** → **Integrations** → **Dedicated integrations** and click **Add an integration**
  3. Select **ntopng** and click **Save**
  4. Open the integration card and copy the **Push URL**

  ### Shared integration

  1. In the Flashduty console, go to **Integration center → Alert events**
  2. Select **ntopng** and enter an integration name
  3. Configure the default route and choose a channel; you can add more rules under **Routes** after creation
  4. Click **Save** and copy the generated **Push URL**
</div>

## In ntopng

***

<Steps>
  <Step title="Create a Webhook endpoint">
    1. Log in to ntopng as an administrator
    2. Go to **Notifications → Endpoints** and click **+**
    3. Choose the **Webhook** endpoint type and name it `Flashduty`
    4. Paste the complete Flashduty Push URL, including `integration_key`, into the webhook URL
    5. Leave **Shared Secret**, **Username**, and **Password** empty. Flashduty authenticates with the `integration_key` in the Push URL and does not check them. If you set a Shared Secret, it is included in every request but never stored in a Flashduty alert
  </Step>

  <Step title="Create a recipient">
    1. Go to **Notifications → Recipients** and click **+**
    2. Select the `Flashduty` endpoint you just created and name the recipient
    3. Change **Notifications Type** to **Alerts**. The default is **Active Scan Reports**, which sends no alerts, so Flashduty receives nothing
    4. Set the minimum severity, alert categories, entity types, and host pools as needed; only alerts that match are sent
    5. Click **Check** to send a test request, then click **Add** to save the recipient
  </Step>

  <Step title="Verify the lifecycle">
    Trigger a host alert (for example, let a host breach one of ntopng's threshold checks) and confirm Flashduty shows an active alert. After the condition clears and ntopng releases the alert, confirm the Flashduty alert recovers.
  </Step>
</Steps>

## Alert Key

***

The `engage` and `release` messages for one alert carry the same interface ID (`ifid`), entity type (`entity_id`), entity value (`entity_val`), alert type (`alert_id`), and subtype (`subtype`). Flashduty builds the Alert Key from these five fields. ntopng itself tells engaged alerts apart by entity value, alert type, and subtype. The score (`score`), timestamps, host name, and check period change between messages and are not part of the Alert Key.

A flow alert has `action` set to `store` and each one becomes its own alert. When ntopng resends the same flow after its conditions change, the Alert Key stays the same: it is built from the interface, alert type, VLAN, client and server IP and port, protocol, and the flow's first-seen time.

If an `engage` or `release` message lacks `alert_id`, `entity_id`, or `entity_val`, Flashduty returns a parameter error that names the field.

## Severity

***

ntopng derives severity from `score`; Flashduty maps it as follows. A missing or non-numeric `score` is treated as Info.

| ntopng `score` | ntopng severity | Flashduty severity |
| :- | :- | :- |
| 100 and above | Error, Critical, Emergency | Critical |
| 50 to 99 | Warning | Warning |
| Below 50 | None, Info, Notice | Info |

## Recovery and testing

***

* **`release`**: closes the alert with the same Alert Key and keeps the severity it had before the release.
* **`store` (flow alerts) and any alert without a release message**: does not recover on its own. Turn on [auto-close](/en/on-call/channel/create-edit) in the integration or channel, with a suggested duration of 24 hours.
* **Check button**: ntopng sends a request with `version` `0.2` and an empty `alerts` list. Flashduty returns success and opens one Info alert titled `ntopng test notification` under its own Alert Key. It never merges with a real alert and does not recover on its own, so close it manually.

A request carries at most 10 alerts (ntopng's per-request limit). Flashduty creates one event per alert and keeps the order of the request.

## Troubleshooting

***

* **ntopng reports a delivery failure**: confirm the webhook URL is complete, includes `integration_key`, and that the ntopng server can reach `api.flashcat.cloud`. ntopng retries a failed delivery 3 times
* **Flashduty returns a parameter error**: check that the body is JSON and that every `engage` and `release` alert has `alert_id`, `entity_id`, and `entity_val`
* **An alert does not recover**: flow alerts have no release message; for other alerts ntopng must release them first, so check on the ntopng **Alerts** page whether the alert is still engaged
* **No alerts arrive**: check the recipient's minimum severity, alert category, and entity filters, and that alert generation is enabled in ntopng

For more detail, see the Endpoints and Recipients section of the [ntopng documentation](https://github.com/ntop/ntopng/blob/dev/doc/src/user_interface/shared/alerts/available_endpoints.rst).