Events
One set of events drives three things: the toasts in the console, the realtime stream, and outbound webhooks.
The envelope
Section titled “The envelope”| Field | |
|---|---|
type |
The event type, listed below |
message |
A short human-readable line, shown in the toast |
permission |
The permission a person must hold to be sent this event |
siteId |
The site the event belongs to, where it belongs to one |
sticky |
Whether the toast stays until dismissed |
data |
Structured payload: ids, loan number, person name |
at |
ISO timestamp |
Submissions
Section titled “Submissions”| Type | Fires when |
|---|---|
submission.created |
A repair is lodged. Sticky when lodged by a client |
submission.status |
Its status changes |
submission.vendor |
It is sent to, or updated by, an external repair vendor |
Tickets
Section titled “Tickets”| Type | Fires when |
|---|---|
ticket.created |
A ticket is raised |
ticket.status |
Its status changes |
ticket.comment |
A reply or an internal note is added. The note version is sent only to people who can read internal notes |
ticket.merged |
Two tickets are merged |
| Type | Fires when |
|---|---|
loan.assigned |
A loan is issued |
loan.returned |
A loan comes back |
loan.registered |
A device is added to a pool |
loan.removed |
A device is removed |
loan.bulk |
A bulk action runs |
loan.synced |
A pool syncs from an MDM smart group |
Service quality
Section titled “Service quality”| Type | Fires when |
|---|---|
sla.breach |
A response or resolution target is missed. One shot per item |
automation.match |
An automation rule matched a new submission |
Monitors
Section titled “Monitors”| Type | Fires when |
|---|---|
monitor.up |
A monitored service recovers |
monitor.down |
It goes down |
monitor.alert |
An alert threshold is reached |
Backups
Section titled “Backups”| Type | Fires when |
|---|---|
backup.success |
A backup completes |
backup.failed |
One does not |
Kiosk and security
Section titled “Kiosk and security”| Type | Fires when |
|---|---|
kiosk.request |
An assistance request is raised at the kiosk |
kiosk.resolved |
It is approved or denied |
security.resolved |
A security approval request is decided |
Where to receive them
Section titled “Where to receive them”In the console. Automatic. This is what makes the desk update itself.
In your own system. Register an outbound webhook. Signed with HMAC-SHA256, and you can filter to specific types.
In a browser client of your own. Subscribe to /api/events with
EventSource, inside an authenticated session.
ticket.comment fires for internal notes too, but not to everybody. A note
generates an event carrying the ticket.internal permission, so only people who
could read the note are told one was added. It still never sends an email. The
note’s text is never in the event either way.
sla.breach fires once per item. A breach that stays breached does not
generate a new event every minute, because people mute an alert that repeats.
submission.created is sticky when the source is a client. A booking made at
the kiosk while nobody was looking at the screen is still there when somebody is.
Order is not guaranteed. Two events fired close together can arrive in either order at a webhook receiver. Build for that.
Who receives them
Section titled “Who receives them”Three filters are applied in order, and all three must pass.
Tenant. A subscriber receives only their own tenant’s events.
Permission. Every event names the permission that governs the record behind
it — a repair event carries repair.view, a kiosk event client.view, a local
administrator password retrieval device.laps.read. Somebody who could not open
the record is not told about it. A role holding * passes this check for
everything. The permission keys are listed in
permissions.
Site. Where the event belongs to a site, only people whose access covers that site receive it. Somebody with no site restriction receives all of them.
Some events belong to no single site — a backup result, a monitor alert, a fleet-wide sync, a bulk loan checkout. Those are treated as unassigned, which means people restricted to a site do not receive them. That is deliberate: the alternative is telling every campus about every other campus.
Webhooks are not filtered this way
Section titled “Webhooks are not filtered this way”An outbound webhook endpoint is configured per school by an administrator, not per person, so there is nobody to check a permission against. Endpoints receive every event for their tenant, filtered only by the types you selected when you registered them. If that is more than you want a system to see, filter by type.