Skip to main content

Overview

V2 uses standard pagination for alert retrieval — no sliding window or num 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
PUT /v2/api/companies/{id}/set-all-alerts-read marks all alerts for the company as read. In multi-tenant or multi-integration setups, only call this when every consumer is caught up.

Building notification rules

Python

Gotchas

  • No sliding window needed. V2 uses standard pagination — fetch all pages, filter by IsRead: false.
  • isRead is now honoured. Unlike V1, V2’s update-read-status correctly sets the read state to the value you pass.
  • AlertType names are available. Use GET /v2/api/companies/{id}/alerts to get the string name for each AlertType integer — no need to build the mapping empirically.
  • UtcTime has no Z suffix but is always UTC — treat it as UTC when parsing.