Skip to main content

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
For more details, see the Svix documentation, and for information on how to verify the payload, see the Svix verify docs.

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 percentage
  • ENERGY_REMAINING - Remaining energy in kWh
  • LOCATION - Vehicle coordinates
  • ODOMETER - Total distance traveled
  • RANGE - Estimated remaining range
  • TIRES - Tire pressure data
  • OEM_ALERT - Diagnostic trouble codes. The mappedCode, affectedComponent, recommendedAction, type and severity fields use a fixed set of values, listed under OEM Alert Vocabulary.
  • CHARGING_STATE - Current charging status
  • DEPARTURE_TIMES - Scheduled departure times
  • CHARGING_WINDOWS - Scheduled charging windows
  • OTHER_CHARGING_DATA - Additional charging metrics
  • OTHER_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 be null, 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.

mappedCode

The normalised fault code. One of 174 values:

affectedComponent

The part of the vehicle the alert relates to. One of 69 values:

recommendedAction

What to do about the alert. One of 21 values:

type

The kind of alert. One of 5 values:

severity

How severe the alert is. One of 4 values: