Introduction
This document outlines the webhooks available for your integration, and how to use them. Webhooks are automated messages sent from our system to yours when a specific event occurs. The payload of each webhook is delivered in JSON format.Using Webhooks
You can subscribe to the webhook events below by going to the webhook page in our Portal. We use the webhook platform svix, and the catalog on that Portal page allows you to:- Add your endpoint for each event you want to subscribe to
- Get the secret key used to verify the payload for that event type (after you have added an endpoint, you will see the key at the bottom of the page)
- Get the complete JSON schema for the event type, including examples (see below for schemas and examples as well)
- Add rate limiting and filtering rules for the event type, and custom headers for each
- Test sending example payloads (set to the correct schema) to your endpoints
- View logs and webhook activity for each event type
Webhook Events
Here are the specific webhook events you can subscribe to.1. device.connected
This event is triggered whenever a new device successfully connects to our platform. This is useful for tracking the provisioning and online status of your devices.
Schema
The complete JSON schema for this event is available here.Example Payloads
2. device.disconnected
This event is triggered whenever a device disconnects from our platform. This is useful for tracking when devices go offline.
Schema
The complete JSON schema for this event is available here.Example Payloads
3. device.telemetry
This event is used to send various types of data and metrics from a device. The specific data included in the payload is determined by the metricType field.
Schema
The complete JSON schema for this event is available here. The schema includes all supported metric types and their detailed field definitions.Supported Metric Types
STATE_OF_CHARGE- Battery charge percentageENERGY_REMAINING- Remaining energy in kWhLOCATION- Vehicle coordinatesODOMETER- Total distance traveledRANGE- Estimated remaining rangeTIRES- Tire pressure dataOEM_ALERT- Diagnostic trouble codes. ThemappedCode,affectedComponent,recommendedAction,typeandseverityfields use a fixed set of values, listed under OEM Alert Vocabulary.CHARGING_STATE- Current charging statusDEPARTURE_TIMES- Scheduled departure timesCHARGING_WINDOWS- Scheduled charging windowsOTHER_CHARGING_DATA- Additional charging metricsOTHER_LOCATION_DATA- Additional location metrics (speed, heading, elevation)
Example Payloads
4. command.updated
This event is triggered when a vehicle command’s status changes (e.g., from PENDING to EXECUTED or FAILED).
Schema
The complete JSON schema for this event is available here.Example Payloads
5. rate_limit.updated
This event is triggered when a rate limit is updated for an API endpoint or service.
Schema
The complete JSON schema for this event is available here.Example Payloads
6. alert.updated
This event is triggered when a custom (as opposed to one directly sent from the device manufacturer) alert’s status, severity, or other properties change. Alerts can be created, resolved, muted, or have their severity updated.
Schema
The complete JSON schema for this event is available here.oemAlerts
When the trigger that fired has conditions on OEM alerts (metadata.oemAlert.*), oemAlerts lists the vehicle’s active OEM alerts that satisfied them, most recent first, with one entry per oemCode. Each entry has the same shape as oemAlert on the OEM_ALERT metric type of device.telemetry, so it carries the manufacturer’s own oemCode, oemMessage and oemMetadata alongside the normalised fields listed under OEM Alert Vocabulary.
An alert definition can watch for several faults, and more than one of them can be active at once, so every active OEM alert that satisfied the trigger is listed. That tells you which of the watched faults were present. Active OEM alerts the trigger doesn’t match are never included.
oemAlerts reflects the vehicle’s active OEM alerts when the alert changed. A change in those OEM alerts on its own, while the alert stays the same, doesn’t send a new event.
oemAlerts is null when the trigger that fired has no OEM alert conditions, such as an alert on a missing odometer reading, and in the rare case that the OEM alerts couldn’t be determined. Otherwise it’s a list, which can be empty when the trigger matched through its other conditions. oemAlerts is only sent on this webhook, and isn’t returned by GET /vehicles/{id}/alerts.
oemAlerts is null on a RESOLVED event, as are currentSeverity, triggerName and triggerDescription, because an alert resolves when none of its triggers match any more. Correlate a RESOLVED event with the earlier ACTIVE one using the alert id.
Example Payloads
7. journey.updated
This event is triggered when a vehicle journey is created or updated. A journey represents a trip taken by a vehicle, including start and end locations, distance traveled, energy consumption, and other metrics.
Schema
The complete JSON schema for this event is available here.Example Payloads
OEM Alert Vocabulary
An OEM alert is a diagnostic message about the vehicle, such as a fault or warning reported by its manufacturer. Volteras maps each one onto a common set of values, so the same fault reads the same way across manufacturers. Any of these fields can benull, for example when an alert has no mapping.
These values appear on the OEM_ALERT metric type of device.telemetry, and on each entry of oemAlerts on alert.updated.

