Portal

Alerts

Real-time device alerts in the e-bon Portal — the six alert types, how each one is derived, where they surface in the UI and how to read them programmatically through the API.

Alerts

Device alerts are e-bon's real-time signal that a fiscal device needs attention. They tell you when a printer is out of paper, when a cover is open, when a Z report is overdue, when fiscal memory is filling up, and when a device has dropped offline for too long.

Alerts are derived deterministically from device state on every read. They are not stored as individual records, and they have no separate lifecycle in the database — every time the Portal or the API computes alerts, it reads the current device status flags, the most recent successful Z report, the device's most recent activity timestamp, and its live WebSocket connection state, and produces the list from scratch. As soon as the underlying condition clears (paper reloaded, cover closed, Z report submitted, device reconnects), the alert simply stops appearing on the next read.

There is no per-alert acknowledge, dismiss or snooze in the data model today. Alerts come and go with the device's actual state. To stop an alert, fix the condition that triggers it.

The six alert types

There are exactly six alert types — no more, no less. Each one carries one of three severities: warning, error or info.

Paper out — `paper_out`

Severity: error
Trigger: the device reports that paper has run out completely.
Message: Paper is out
What to do: load a new paper roll on the AMEF — the device cannot print receipts until you do.

Paper low — `paper_low`

Severity: warning
Trigger: the device reports that paper is nearly out (near-end sensor).
Message: Paper is running low
What to do: load a new paper roll on the AMEF before it runs out mid-receipt.

Cover open — `cover_open`

Severity: error
Trigger: the device reports that the printer cover is open.
Message: Cover is open
What to do: close the printer cover. The device cannot print receipts while the cover is open.

Fiscal memory almost full — `fiscal_memory_almost_full`

Severity: warning
Trigger: the device reports that fiscal memory is almost full.
Message: Fiscal memory is almost full
What to do: plan an authorised service intervention to swap the fiscal memory module before it fills completely. Once full, the AMEF will refuse to issue new receipts until serviced.

Z report overdue — `z_report_overdue`

Severity: warning
Trigger: more than 24 hours have passed since the last successful Z report — or no Z report has ever been submitted from this device.
Message: Z report not submitted in over 24 hours
What to do: submit a Z report for the device — from the e-bon app on the device, or from the Portal's fiscal operations flow.

Disconnected — `disconnected`

Severity: error
Trigger: the device has been offline for more than 1 hour — no live connection to the e-bon backend and no recent activity.
Message: Device disconnected for over 1 hour
What to do: check power, network and the on-site Android controller running the e-bon app. The alert clears automatically once the device reconnects.

Where you see alerts in the Portal

Device list badge

On Devices, each device card carries an alert count badge when at least one alert is open. The badge colour reflects the highest severity present: red when any alert is error, amber when the highest is warning. A device with zero alerts shows no badge. The list updates in real time — both via a periodic refresh and via the device.alert realtime event delivered over the Portal's WebSocket channel.

Device Detail → Overview

Open a device from the list and the Overview tab lists every open alert for that device, sorted by severity, with the alert's message and the time it was first detected. As soon as the underlying condition clears the row drops off the next read.

Filter the API by severity

The API accepts a severity=warning|error|info query parameter so dashboards or external tooling can surface a single severity tier — see the API section below.

Who gets notified

Alerts that fire on a device also drive email notifications to the recipients you have configured for your organisation. Recipients subscribe per category (alerts, reports, billing, events) and receive only the categories they have opted into. The recipient list and category subscriptions are managed on the dedicated Notifications page — that page is the single source of truth for who gets what.

Email is the only notification channel today. There is no SMS, no web-push, no in-app push notification surface beyond the Portal UI itself.

The API

Programmatic access to alerts is exposed through a single batch endpoint scoped to the organisation: GET /api/v1/devices/alerts. It returns derived alerts for every device in the calling organisation, keyed by device id, and accepts an optional severity=warning|error|info filter so dashboards can surface a single tier.

For the request shape, response payload, severity enum, and full list of alert type values, see API → Devices: Alerts. For the typed SDK wrapper around the same endpoint see SDK → Devices.

Where to next

Devices — the device list and Device Detail page where alerts surface in the UI.
Notifications — configure the email recipients and per-category subscriptions that drive alert emails.
API → Devices — the broader devices REST surface.
SDK → Devices — typed client methods for fetching alerts and the rest of the devices API.

Operators

Add and manage operators (cashiers, waiters, shop managers) on a fiscal device from the Portal — Set Operator flow on the Device Detail Operations tab, with capabilities queried live from the AMEF.

Sign-up & Sign-in

Create your e-bon account, sign in to the Portal, and reset a forgotten password at e-bon.ro.