We’ve introduced several improvements to make the Azuga Developer Portal easier to navigate and faster to onboard:

Guides (New): Step-by-step documentation covering getting started details, OAuth 2.0 authentication, and Azuga Postman Collection (V4) setup. More guides will be added over time.

Recipes (New): Task-focused workflows to help developers complete common actions. The first recipe, Get your access token via V4 Authentication API, walks through OAuth 2.0 token generation.

Migration Guide (v1 → v4): A new guide to help teams migrate to API v4, highlighting key changes, improved authentication, standardized data models, and better error handling.

Postman Collection (V4): A refreshed Postman collection to quickly authenticate and test V4 APIs, updated alongside new APIs and enhancements.

1. Explore Alert API Documentation, now part of the V4 API architecture, delivers
   seamless integration, enhanced performance, and reliability for all users.
2. The enhanced Alerts API offers CRUD operations of alert, alertTypes and alertPolicies improved documentation, including detailed descriptions of requests, responses, data types, and example payloads to simplify
   integration. These updates ensure clearer implementation and a smoother experience for
   developers.

Added searchColumn and searchValue query parameters to the List Service Types endpoint, enabling targeted search based on specific fields.

Posted Events

These events provide clearer insights into vehicle speed-related activities and compliance with road speed limits.

• Posted Over Speeding Event Posted Speed Alert Posted Speed Limit

Requested Media Events

These events offer improved transparency into media request processing, helping developers better track the availability, status, and outcomes of requested media files.

• Requested Media Available Requested Media Failed Requested Media Partially Available
• Requested Media Pending Requested Media Submitted Requested Media Unavailable

• Introduced v4 Authentication Mechanism
  • Generates an access token and refresh token using a user’s username and password for authentication.
  • Tokens are intended for use with other v4 endpoints via the Authorization: Bearer <access_token> header.

Behavior

• Authentication is now handled through the v4-specific login endpoint, consistent with other v4 resources.
• Error responses for invalid credentials and related issues follow the standard v4 error format and HTTP status codes.

Notes for integrators

• Existing integrations using v3 authentication flows can use the same access token, nothing would get affected.
• Existing integrations using v1 and v2 APIs have to mandatorily use v4 Authentication Mechanism for obtaining tokens.
• New integrations targeting v4 can use this endpoint as the primary mechanism for obtaining tokens.

Low Tire Pressure, High Tire Pressure, and TPMS Resolved webhook events are now included in the webhook documentation. These events help improve visibility into tire health and provide timely alerts for safety-related conditions.

• Low Tire Pressure Event
• High Tire Pressure Event
• TPMS Resolved Event

We’re excited to announce that Accident Detection, Driver Pair message, and Driver Unpair message webhook events have now been added to the webhook documentation on the Azuga Developer Portal! These updates expand our event catalog and strengthen integration capabilities for partners and customers.

📡 Published Events

✅ Accident Detection ✅ Driver Pair Message ✅ Driver Unpair Message

📘 Each event includes detailed documentation covering:

🔹 Webhook Categorisation – Classification based on module and functionality
🔹 Event Name – Standardized event type
🔹 Event Description – Clear explanation of the use case and purpose
🔹 Subscription Package – If applicable
🔹 Trigger Condition – Exact conditions under which the event is triggered
🔹 Payload – Complete JSON structure sent via webhook
🔹 Payload Reference – Field-by-field explanation and examples` 

📄Event Summaries

1️⃣Accident Detection:

The Accident Detection webhook is triggered when the device detects a potential or confirmed collision, enabling fleets to react quickly to safety incidents with real-time crash data.

For more information refer Accident Detection

2️⃣ Driver Pair Message

The Driver Pair webhook notifies when a driver successfully pairs with a vehicle using an input method such as iButton, RFID, or mobile authentication. This helps maintain accurate driver-to-vehicle assignment records.

For more information refer Driver Pair Message

3️⃣ Driver Unpair Message

The Driver Unpair webhook triggers when a paired driver disconnects from a vehicle—either automatically at trip end or when manually unpaired. This keeps integrated systems up to date with driver assignment changes.

For more information refer Driver Unpair Message

More webhook events will continue to be added to enhance automation, safety monitoring, and integration flexibility.

Updated Base Url for v4 apis.
Refer here

🔍 What’s New?

Health Report capabilities:

1. Fetch Health Report Data
2. Fetch Scheduled Health Report
3. Schedule Health Report
4. Update a Scheduled Health Report
5. Delete a Scheduled Health Report
6. Validate Report Name for Scheduled Reports

🔗 Explore the Docs: SafetyCam Health Report – API Reference

We’re excited to share that additional webhook events have been added to our Phase 2 documentation Azuga Developer Portal! These updates expand event coverage and enhance the clarity and utility of our integration tools.

📡 Published Events:

✅ Fuel Events (Fuel Increase, Fuel Decrease, Fuel Level Remaining %, and Low Fuel)
✅ Vehicle Events (Vehicle Creation, Vehicle Updation, and Vehicle Deletion)
✅ Oil Life Remaining (%)
✅ GPS Message
✅ Hard Acceleration
✅ Hard Braking
✅ Hardcore Braking
✅ Over Speeding (Overspeeding and Overspeeding Ended)
✅ Seat Belt
✅ Trip Events (Trip Start and Trip End)

📘 Each event includes comprehensive documentation:

  🔹 Webhook Categorisation  - Classification of Webhook Events Based on Module Features
  🔹 Event Name
  🔹 Event Description
  🔹 Subscription Package if Required
  🔹 Trigger Condition – When and why the event triggers
  🔹 Payload – Full event payload structure
  🔹 Payload Reference – Field-level descriptions and examples

More events will be added in the future to expand integration capabilities.