New Features and Enhancements
Combined Video Download for AI-12 and AI-14 Devices
Surfsight® Cloud now supports Combined Video Download for AI-12 and AI-14 dual-lens devices, allowing users to generate and download a single, synchronized MP4 video that combines road-facing and in-cab camera views into one unified file.
Users can now:
- Download a single, synchronized MP4 video showing both inside and outside camera angles aligned by absolute capture time.
- Reduce the need to manage separate video files or coordinate staggered playback across multiple media player windows.
- Share a self-contained video file with insurance adjusters, law enforcement, or legal counsel without granting external parties access to the platform.
Scope: - Applies to Surfsight AI-12 and AI-14 dual-lens devices.
- Cloud platform and API capabilities; no device hardware or firmware updates required.
Fixes
Surfsight MyGeotab add-in updates for Geotab API guidelines
This release updates the Surfsight add-in for the MyGeotab portal to help align with Geotab's API standards and best practices for data retrieval and integration stability.
Previously, device retrieval calls did not implement pagination under Geotab's 5,000-record limit, and retry behavior during repeated API failures could risk exceeding allowed call rate limits.
With this update:
- Device retrievals implement pagination designed to work within the 5,000-record maximum limit (
resultsLimit), helping to support device synchronization for fleets of varying sizes. - API retry behavior is designed to align with Geotab rate limiting guidelines to help reduce the likelihood of exceeding allowed call volumes during intermittent failures.
- Visibility and handling for persistent API failures are enhanced to help maintain reliable communication between the Surfsight add-in and MyGeotab.
AI-14 device configuration synchronization following upgrade
This release resolves an issue where configuration settings were not automatically evaluated and re-sent to AI-14 devices following a device upgrade.
Previously, after upgrading an AI-14 device, the system did not check whether settings from the Organization profile that were previously not applicable should now apply to the upgraded device. As a result, newly applicable configuration settings were not synced automatically to the device.
With this update:
- AI-14 upgrade behavior is aligned with AI-12 devices to evaluate the Organization profile for newly applicable settings following an upgrade.
- Configuration settings are automatically re-sent and synchronized with the AI-14 device.
Improved device connectivity status reporting during connection re-establishment
This release resolves an issue where online devices were intermittently reported with a false-positive offline status in the cloud portal.
Previously, during transient network re-connections or session takeovers in the messaging broker (EMQX), disconnect events—such as taken over or discarded sessions—were incorrectly processed as device disconnects, causing active devices to be erroneously marked as offline.
With this update:
- Cloud device connectivity services now evaluate disconnect reasons, ignoring transient session takeover and discarded events during re-connection.
- Device connectivity states are designed to better reflect online and offline status across the fleet.
Improved occurrence timestamps in simulated alarm webhook payloads
This release resolves an issue where the firstOccurrence and lastOccurrence timestamps in simulated alarm webhook payloads displayed incorrect values.
Previously, when generating simulated alarms via the alarm simulator API (/v2/devices/{imei}/alarm-simulator), the firstOccurrence and lastOccurrence fields in the alarm webhook payload were mapped to the alarm definition's creation timestamp (alarmDefinition.createdAt) rather than the event's actual simulated occurrence time.
With this update:
- Simulated alarm webhook payloads map
firstOccurrenceandlastOccurrenceto the specified simulated alarm timestamp. - Partner and customer integrations receiving alarm payloads can reflect the simulated occurrence time during simulation and testing workflows.
Breaking Changes
The following breaking changes were announced on November 1, 2026, and will be implemented on or after January 31, 2027.
Admin and driver PIN changes
Summary
Admin and driver PINs now have stricter rules. Your existing PINs keep working. The rules only apply when you set or change a PIN.
New rules
- PINs must be exactly 4 characters.
- 29 commonly used or sequential values are now restricted (list below). Before this release, only 4121 was restricted.
A PIN that breaks a rule is rejected with 400. For a restricted value, the message is: "The provided code is not available for use as adminPin, driverPin, or technicianPin. Choose a different code."
Existing PINs keep working
A PIN that's already stored is accepted when you send it back unchanged, even if it's restricted:
- Single device (PUT /devices/{imei}/device-config): the PIN must match the PIN stored on the device.
- Organization settings (POST /organizations/{orgId}/device-settings): the PIN must match the organization's saved PIN.
- Bulk (PUT /devices/device-config): every selected device must already have that PIN. Otherwise, the whole request is rejected.
Changing a PIN to a restricted value is rejected.
Action needed
API integrators: the error message has changed from "The code 4121 is not available…". Update any logic that matches on the old text.
Restricted values
0000 1111 2222 3333 4444 5555 6666 7777 8888 9999 0123 1234 2345 3456 4567 5678 6789 3210 4321 5432 6543 7654 8765 9876 1212 2112 2580 4121 6969