Alerts and notifications

Threshold rules

They are defined per device type in the catalog (ROOT): telemetry field, condition (>, ≥, <, ≤), threshold and severity (warning / critical). Ingestion evaluates them on every reading.

Lifecycle

reading breaches → ACTIVE ──(user)──► ACKED
        │                        │
        └── reading back in range ──► RESOLVED

• While it keeps breaching, the open alert is updated (not duplicated).
• An acknowledged alert (ACKED) never goes back to ACTIVE: if the value normalizes and breaches again, a new alert is opened.

API

Endpoint	Use
GET /v1/alerts?state=ACTIVE&severity=critical	Scoped listing, ordered by date
POST /v1/alerts/:id/ack	Acknowledge an active alert
GET /v1/alerts/summary	Counters for badges ({active, critical, warning})
PUT /v1/device-models/:id/alert-rules	Replace the type’s rules (ROOT)

Email notifications

Each user manages their notification rules through the API (GET/POST/PATCH/DELETE /v1/notification-rules):

• Alert raised (alert.raised) — optionally critical only.
• Binding requested (binding.requested, ROOT only) — includes the ICC of the SIM for its activation on the operator’s platform.

Notices are recorded in a history (outbox) and sent with the corporate template. Automatic transactional emails are also sent: welcome on registration, binding approved, password change and the two-step verification PIN.