Overview
V2 uses standard pagination for alert retrieval — no sliding window ornum cap required. Alerts are returned as AlertDto records from GET /v2/api/companies/{id}/alert-records.
Key fields per alert:
V2 adds
GET /v2/api/companies/{id}/alerts which returns your alert configurations — including the human-readable AlertType string (e.g. "Speeding", "Geofence"). Use this to build your type mapping instead of discovering it empirically.Step 1 — Look up alert type names
Before polling, fetch your alert configurations to build a type-ID-to-name map:Python
Step 2 — Poll with pagination
GET /v2/api/companies/{id}/alert-records supports standard page/pageSize pagination. Filter by IsRead to process only unread alerts.
Step 3 — Filter by alert type
Use the config map from Step 1 to route alerts to the appropriate handler:Python
Step 4 — Acknowledge alerts
Mark one alert as read
PUT /v2/api/alerts/{id}/{date}/update-read-status accepts a JSON body. In V2, isRead is honoured — you can mark an alert as unread by passing false.
cURL
Python
Bulk clear all alerts
When you want to reset the unread state for the entire company:cURL
Building notification rules
Python
Gotchas
- No sliding window needed. V2 uses standard pagination — fetch all pages, filter by
IsRead: false. isReadis now honoured. Unlike V1, V2’supdate-read-statuscorrectly sets the read state to the value you pass.AlertTypenames are available. UseGET /v2/api/companies/{id}/alertsto get the string name for eachAlertTypeinteger — no need to build the mapping empirically.UtcTimehas noZsuffix but is always UTC — treat it as UTC when parsing.