Skip to content

Action Types

This page explains all built-in action types, their configuration options, and the exact payloads they produce. It is aimed both at people who just want to be notified of alerts and at people integrating Nzyme with their own systems (SIEMs, chat, ticketing, automation).

Info

Make sure to read the Alerting Overview and Subscriptions & Actions pages first. They explain how events are generated and how you subscribe actions to them.

Event supertypes

Every action receives one of two kinds of event. The supertype is always present in the payload as event_supertype and is the first thing you should branch on when integrating.

Supertype event_supertype value Raised when
System event system An operational event occurs in Nzyme itself (e.g. an authentication or organization change).
Detection event detection A detection alert is raised or re-activated.

The fields carried by each supertype differ slightly, and they also differ between transports. The Field reference section below lists exactly which fields appear where.

Common fields

These fields are present on both supertypes and all transports that emit structured payloads:

Field Description
timestamp Time the underlying event occurred, in ISO 8601 with timezone offset (e.g. 2026-07-27T09:11:05.223-05:00).
event_supertype Either system or detection.
event_type Machine-readable event type identifier. Stable across releases; safe to key alerting rules on.
event_type_human_readable A short human-friendly title for the event type. May change between releases; do not key rules on it.
details Free-form, human-readable description of the specific occurrence. Content varies per event and may include values such as usernames or network names.

Supertype-specific fields

Field Present on Description
event_type_category system High-level category of the system event.
event_type_description system Longer static description of the event type. Deliberately omitted by the Syslog action to keep messages compact. (see the Field reference).
event_type_subsystem detection Identifier of the subsystem that produced the detection.

When do actions run?

Understanding when an action fires matters most for SIEM and automation integrators, because Nzyme does not emit one message per observed frame or per detection tick. Detection alerts are grouped and re-triggered on a timer, so you will receive far fewer messages than there are underlying observations. The full lifecycle of grouping, re-triggering, the active/inactive window, and what happens when alerts are resolved or deleted, is described in the Alerting Overview.

Two things worth keeping in mind while integrating:

  • You receive a message on the first detection and then, at most, one further message each time the condition lapses and recurs. Design downstream correlation rules around this "first seen / re-triggered" model rather than expecting a continuous stream.
  • The Webhook and Syslog actions attempt delivery once per event. There is no built-in retry or queue. Failures are written to the Nzyme log and the event is not re-delivered. If you need guaranteed delivery, place a durable collector (e.g. a local syslog relay or a webhook receiver with its own queue) between Nzyme and your SIEM.

Email / SMTP

The email action sends a formatted notification email to a list of receivers. It is intended for humans (a SOC inbox, the system administrators of a cluster), not for machine-to-machine integration.

Requirements

Email actions rely on a cluster-wide SMTP server that a super administrator configures on the Integrations page, including the transport strategy (SMTP, SMTP TLS, or SMTPS), host, port, credentials, from-address, and the Nzyme web interface URL. If the SMTP configuration is incomplete, the email action cannot be created and Nzyme logs an error instead of sending.

Configuration

Option Description
Subject Prefix Prepended to every generated subject. Defaults to [nzyme].
Receivers One or more recipient email addresses. All receivers are placed on the To line.

Behavior

  • The subject is generated automatically and combines the prefix with the event, for example [nzyme] Detection Event: <title> or [nzyme] System Event: <human readable name>.
  • Each email is sent as multipart plain-text and HTML, so it renders in any mail client.
  • The body contains the event's human-readable name, its machine event_type, the details, and the event timestamp. The HTML version also links back to the Nzyme web interface.
  • If an email action has no receivers configured, nothing is sent.

Webhook

The Webhook action sends an HTTP POST request with a JSON body to a URL of your choice. Optionally, you can add an Authorization header Bearer token for authentication.

Configuration

Option Description
Webhook URL Target URL. Must start with http:// or https://.
Allow Insecure When enabled, disables TLS certificate and hostname verification for https URLs (see below).
Bearer Token Optional. Sent as Authorization: Bearer <token>. Stored encrypted in the Nzyme database.

Note

Because the bearer token is encrypted at rest, it cannot be shown back to you when editing an action. To keep a token you must re-enter it; leaving the field blank on edit removes the token from the action.

Request format

Property Value
Method POST
Content-Type application/json
Body A single JSON object describing one event (see Webhook payloads).
Authorization Authorization: Bearer <token> header, sent only if a bearer token is configured.

Each request carries exactly one event. Your receiver should respond quickly (see Timeouts).

TLS and certificate verification

By default the Webhook action performs normal TLS certificate and hostname verification when the target URL uses https. Enabling Allow Insecure turns both off, allowing endpoints with self-signed or otherwise untrusted certificates.

Warning

Enabling Allow Insecure makes the connection vulnerable to man-in-the-middle interception, and your event payloads (which may contain sensitive details) can be read or altered in transit. Use it only for trusted, network-isolated endpoints, and prefer a properly trusted certificate wherever possible.

Timeouts, retries, and success

  • Timeouts: connect, read, and write timeouts are each 15 seconds.
  • Success: a 2xx status code is treated as success. Any other status code is treated as a failure and logged.
  • Retries: none. Each event is delivered with a single attempt.

Webhook Payloads

The JSON structure of the payloads is the following:

System Event

{
  "event_type":"AUTHENTICATION_SUPERADMIN_MFA_RESET",
  "event_type_category":"AUTHENTICATION",
  "event_type_human_readable":"A super administrator MFA method was reset",
  "details":"MFA method of super administrator [[email protected]] was reset by [[email protected]]",
  "event_supertype":"system",
  "event_type_description":"Multi-factor method for a super administrator user has been reset, either by the user themselves or by an administrator.",
  "timestamp":"2026-07-27T17:12:06.228-05:00"
}

Detection Event

{
  "event_type":"MONITOR_TRIGGERED",
  "event_type_subsystem":"GENERIC",
  "event_type_human_readable":"Monitor triggered",
  "details":"Monitor \"WiFi Monitor Example\" triggered.",
  "event_supertype":"detection",
  "timestamp":"2026-07-27T09:11:05.223-05:00"
}

Note

JSON object key ordering is not significant and is not guaranteed to be stable. Parse by key, never by position, and read fields defensively. Not every field is present on every event (see the Field reference).

Syslog

The Syslog action sends an RFC 5424 formatted message via UDP to a host and port of your choice.

Configuration

Option Description
Protocol Only UDP Syslog (RFC 5424) is supported.
Syslog Hostname Value used as the HOSTNAME field of the message. Defaults to nzyme. Useful for telling multiple Nzyme installations apart.
Destination Host Name or IP address of the host to send messages to.
Destination Port Destination port number. Defaults to 514.

Transport

The only supported protocol is UDP_RFC5424. Consequences worth planning for:

  • UDP is fire-and-forget. There is no delivery confirmation, ordering guarantee, or retransmission. Lost datagrams are simply lost.
  • One event per datagram. Each event is sent as a single UDP packet. There is no streaming.
  • No TCP or TLS transport is available. If you need encrypted or reliable transport, point the action at a local syslog daemon (like rsyslog or syslog-ng) and forward onward over TCP/TLS with queuing.

Message anatomy (RFC 5424)

Each message follows the RFC 5424 layout:

<PRI>VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP STRUCTURED-DATA SP MSG

Nzyme fills these as follows:

Field Value
PRI Always 133 (see Facility and severity).
VERSION 1.
TIMESTAMP The event timestamp, in ISO 8601 with offset.
HOSTNAME The configured Syslog Hostname (e.g. nzyme1)
APP-NAME Always nzyme.
PROCID - (nil).
MSGID - (nil).
STRUCTURED-DATA One SD element carrying the event fields (see below). It also repeats the event time as a timestamp parameter.
MSG The event's details string.

Facility, severity, and PRI

Messages are emitted with a fixed facility and severity:

  • Facility 16 (local0)
  • Severity 5 (notice)

The priority value is therefore always 16 * 8 + 5 = 133, regardless of the alert's own importance, so do not infer alert severity from the syslog PRI. Use the event_type (and, for detections, event_type_subsystem) instead.

Structured data and the SD-ID

The event fields are carried in a single RFC 5424 structured-data element. The SD-ID encodes the supertype plus Nzyme's enterprise number 63705:

  • System events use SD-ID system@63705.
  • Detection events use SD-ID detection@63705.

Each field becomes an SD-PARAM in the form name="value". Keying your parser on the SD-ID (system@63705 / detection@63705) is the most robust way to select and classify Nzyme messages.

Note

SD-PARAM ordering within the element is not guaranteed. Parse parameters by name, not position. The example messages below happen to show one ordering, but yours may differ.

Escaping and sanitization

Nzyme applies RFC 5424 escaping and sanitization so that messages remain well-formed:

  • SD-PARAM values have \, ", and ] escaped with a leading backslash (\\, \", \]). Un-escape these when reading values.
  • SD-PARAM names have ], [, whitespace, =, and " replaced with _, and are truncated to 32 characters (the RFC 5424 SD-NAME limit).
  • The hostname has any character outside A–Z, a–z, 0–9, -, and . replaced with _, and is truncated to 255 characters. An empty hostname becomes -.
  • The MSG (details) portion is not escaped. It is appended as-is after the structured data. Treat everything after the closing ] and its following space as the free-form message.

Syslog Structure

Take note of the different SD-ID values of system and detection as well as the hostname nzyme1, which is configured in the action settings.

System Event

<133>1 2026-07-27T15:09:02.627-05:00 nzyme1 nzyme - - [system@63705 event_type="AUTHENTICATION_SUPERADMIN_MFA_RESET" event_type_category="AUTHENTICATION" event_type_human_readable="A super administrator MFA method was reset" event_supertype="system" timestamp="2026-07-27T15:09:01.722-05:00"] MFA method of super administrator [[email protected]] was reset by [[email protected]]

Detection Event

<133>1 2026-07-27T09:11:05.237-05:00 nzyme nzyme - - [detection@63705 event_type="MONITOR_TRIGGERED" event_type_subsystem="GENERIC" event_type_human_readable="Monitor triggered" event_supertype="detection" timestamp="2026-07-27T09:11:05.223-05:00"] Monitor "WiFi Monitor Example" triggered.

Integration tips (Syslog)

  • Select and classify messages by SD-ID (system@63705 / detection@63705), then read SD-PARAMs by name.
  • Some strict RFC 5424 parsers expect a UTF-8 BOM before the MSG. Nzyme does not prepend one. If your collector relies on the BOM to detect encoding, configure it to assume UTF-8.
  • If reliability or encryption matters, run a local syslog daemon as a relay: point the action at 127.0.0.1, then forward to your SIEM over TCP/TLS with queuing.

Field reference

The tables below show exactly which fields each supertype emits on each transport. A blank cell means the field is not present.

System events

Field Webhook Syslog
timestamp ✓ ✓
event_supertype ✓ ✓
event_type ✓ ✓
event_type_category ✓ ✓
event_type_human_readable ✓ ✓
event_type_description ✓
details ✓ ✓ (as MSG)

Note

event_type_description is intentionally omitted from Syslog messages to keep them compact enough for typical syslog transport. If your integration needs that field, source system events from the Webhook action.

Detection events

Field Webhook Syslog
timestamp ✓ ✓
event_supertype ✓ ✓
event_type ✓ ✓
event_type_subsystem ✓ ✓
event_type_human_readable ✓ ✓
details ✓ ✓ (as MSG)

Note

In both transports the details are a discrete field, but in Syslog they are the RFC 5424 MSG portion (after the structured data), not an SD-PARAM.