ntopng now ships with a native
Flowtriq notification endpoint

Back to Blog

What Happened

We submitted a pull request to ntopng, the open-source network traffic monitoring tool maintained by ntop. The PR adds Flowtriq as a native notification endpoint, the same way ntopng already supports Slack, Telegram, Mattermost, PagerDuty, and other integrations. It was reviewed and merged on July 14, 2026.

This means that any ntopng deployment running a version that includes this change can send alerts directly to Flowtriq without writing custom scripts, configuring generic webhooks, or building middleware. You select Flowtriq from the notification endpoint list, enter your webhook URL and API key, and it works.

How to Set It Up

In your ntopng web interface:

1. Go to Notifications > Endpoints and click Add Endpoint.
2. Select Flowtriq from the endpoint type dropdown.
3. Enter your Webhook URL (your Flowtriq instance's inbound webhook, e.g. https://flowtriq.com/api/v1/webhooks/inbound).
4. Enter your API Key (found in the Flowtriq dashboard under Settings > API).
5. Click Test to verify connectivity, then save.

Next, create a Recipient that uses your new Flowtriq endpoint, and assign it to whichever alert categories you want forwarded (e.g., flow alerts, host alerts, SNMP alerts).

That is the entire setup. No syslog parsing, no webhook relay, no glue code.

How It Works Under the Hood

The endpoint follows ntopng's standard notification module pattern. When alerts fire, ntopng queues them internally. The Flowtriq endpoint dequeues up to 10 alerts per request, decodes nested JSON fields (including flow risk info), and sends them as a structured payload via HTTP POST with Bearer token authentication.

The JSON envelope looks like this:

{
  "source": "ntopng",
  "timestamp": 1721500000,
  "alerts": [
    {
      "alert_id": 42,
      "alert_category": "flow",
      "severity": "warning",
      "json": {
        "cli.ip": "203.0.113.10",
        "srv.ip": "198.51.100.5",
        "proto.ndpi": "DNS",
        "flow_risk_info": { ... }
      }
    }
  ]
}

Flowtriq's inbound webhook auto-detects the ntopng source field and normalizes the payload into its standard alert format. From there, your existing escalation policies take over: kernel-level rate limiting, FlowSpec filters, or RTBH routes depending on severity and your configured thresholds.

The endpoint includes retry logic (3 attempts on failure) and respects ntopng's iteration timeout to avoid blocking the notification pipeline. If Flowtriq is temporarily unreachable, alerts are retried on the next dequeue cycle rather than dropped.

Why This Matters

ntopng is widely deployed across ISPs, hosting providers, and enterprise networks for deep packet inspection and flow analysis. It sees traffic patterns that pure flow collectors miss: application-layer protocols via nDPI, DNS tunneling, TLS fingerprint anomalies, and lateral movement indicators.

Before this integration, connecting ntopng alerts to automated mitigation required building a webhook relay or polling syslog. That meant custom code, maintenance overhead, and latency in the detection-to-mitigation loop. With a native endpoint, the path is direct: ntopng detects an anomaly, Flowtriq receives the alert, and mitigation rules deploy automatically.

For operators already running both tools, this turns a manual workflow into a zero-touch pipeline.

Complementary Detection Layers

ntopng and Flowtriq detect different things at different layers, and the overlap is intentional.

• ntopng operates at the traffic analysis layer: it classifies protocols via nDPI, tracks per-host and per-flow metrics, identifies application-level anomalies, and maintains historical data for forensics.
• Flowtriq's ftagent operates at the per-server level with 1-second detection windows, classifying attack vectors and applying kernel-level mitigation in-line.

Running both gives you depth (ntopng's protocol-aware analysis and historical context) plus speed (ftagent's sub-second detection and local mitigation). The native notification endpoint connects these two layers without any intermediary.

Testing the Integration

After configuring the endpoint, use the built-in Test button in ntopng's notification settings to verify connectivity. This sends an empty alert payload to your Flowtriq webhook and confirms the API key is valid.

For a more thorough test, trigger a real alert in ntopng (e.g., set a low threshold on a host alert policy for a test IP) and verify it appears in your Flowtriq dashboard under Activity > Webhook Events.

You can also verify from the command line:

curl -s https://flowtriq.com/api/v1/webhooks/inbound \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "ntopng",
    "timestamp": 1721500000,
    "alerts": [{
      "alert_id": 1,
      "severity": "warning",
      "json": {
        "cli.ip": "203.0.113.10",
        "srv.ip": "198.51.100.5"
      }
    }]
  }'

The Contribution

The PR added four files to the ntopng codebase:

• scripts/lua/modules/notifications/endpoints/flowtriq.lua - the endpoint module handling alert dequeue, JSON formatting, and HTTP delivery
• httpdocs/templates/pages/notifications/flowtriq/flowtriq_endpoint.template - the UI form for configuring webhook URL and API key
• httpdocs/templates/pages/notifications/flowtriq/flowtriq_recipient.template - recipient template (no per-recipient config needed)
• scripts/locales/en.lua - i18n strings for the endpoint UI and validation messages

The implementation follows the same patterns used by ntopng's existing Mattermost and Webhook endpoints, so it fits naturally into the codebase. We chose to batch alerts (up to 10 per request) to reduce HTTP overhead while keeping payloads small enough for reliable delivery.

Back to Blog

Related Articles