# Release Notes This page outlines the new features, API enhancements, known limitations, and technical support for Qualcomm Aware releases. ## Version: GA 2.10.0 Source: [https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html](https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html) This page outlines the changes and enhancements introduced in the GA 2.10.0 release of the Aware Cloud Platform. This release focuses on strengthening device lifecycle management and enabling scalable firmware operations for QCX217‑based devices. Key highlights include the introduction of FOTA as a Service, allowing centralized orchestration and deployment of firmware updates across device fleets through the Aware platform. Collectively, these updates simplify firmware management, reduce operational overhead, and enhance reliability and control for Aware‑enabled deployments. **Release Date:** June 23, 2026 ### New features - **FOTA as a Service for QCX217 Devices** - This release introduces FOTA (Firmware Over‑The‑Air) as a Service for QCX217‑based Aware modules, focusing on simplifying firmware lifecycle management and enabling scalable update operations. - **Centralized Firmware Management** Firmware updates can now be orchestrated centrally through the Aware platform: - Enables cloud‑driven scheduling and execution of firmware upgrades - Supports consistent update rollout across device fleets - Improves reliability and control of firmware deployment operations - **Scalable Fleet-Wide Rollout** The platform now supports efficient firmware distribution at scale: - Enables staged and large‑scale rollout strategies across devices - Reduces operational complexity in managing updates for high‑volume deployments - Improves overall efficiency of device fleet maintenance These enhancements streamline firmware update workflows, reduce manual intervention, and provide a more robust and scalable mechanism for managing firmware across QCX217‑based deployments. For more information, reach out to the [Aware support](https://mysupport.qualcomm.com/aware/s/) team. ### Aware API enhancements To support scalable and maintainable device management, the legacy `/trackers/` API structure is transitioning to a more unified and flexible `/devices/` API framework. This migration is designed to simplify configuration workflows across individual devices, groups, and asset types, while reducing operational overhead. By adopting the proposed APIs, developers can ensure consistent configuration practices, streamline bulk operations, and improve the overall reliability and scalability of device management systems. The following section outlines key changes and provides actionable guidance to facilitate a smooth transition. **Migration Guide** This migration aims to: - Streamline device configuration management. - Enable consistent configuration across individual devices, groups, and asset types. - Improve maintainability and scalability of configuration workflows. - Reduce operational overhead through standardized and simplified APIs. Table : Individual Device Configuration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Individual Device Configuration | `GET /v1/trackers/{serialNumber}/config*` | `GET
/v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response
includes `deviceConfiguration` and
`pendingDeviceConfiguration`. | | Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH
/v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for
partial updates. | | New endpoint | – | `POST
/v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset
type. | Table : Bulk Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Bulk Configuration Update | `POST
/v1/devices/bulk/configuration/update*` | `POST
/v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in
bulk. | | Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on
`assetTypeId`. | | Bulk Tracker Config | `POST /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better
scalability. | Table : Group Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under
`/devices/groups/`. | | Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by
`assetTypeId`. | \* These APIs have been marked as "TO BE DEPRECATED" starting with the 2.4.0 release. Please migrate to the recommended alternatives. For assistance, reach out to the [Aware support](https://mysupport.qualcomm.com/aware/s/) team. **Request and response changes** Request enhancements: - **Standardized paths**: All new APIs use `/devices/` instead of `/trackers/`. - **Asset Type Support**: New APIs allow applying configurations by `assetTypeId`. - **PATCH over PUT**: Use `PATCH` for partial updates to avoid overwriting unchanged fields. Response improvements: - **Structured JSON**: Responses now return `pendingDeviceConfiguration` in addition to the current configuration on the device. **Notes and best practices** - **Bulk Limits**: All bulk APIs should enforce a configurable limit (default: 50 devices per request). - **Deprecation Awareness**: Avoid using deprecated `/trackers/` endpoints in new implementations. - **Consistency**: Use assetType-based APIs for scalable and consistent configuration across device types. The legacy APIs marked as TO BE DEPRECATED will continue to be available during the transition period to support a smooth migration from the `/trackers/` framework to the new `/devices/` structure. This ensures backward compatibility and allows teams to update their integrations incrementally. Importantly, there were no breaking changes introduced, so existing implementations will continue to function as expected while teams adopt the new APIs. **Action items for developers** 1. **Audit** existing usage of `/trackers/` APIs in your services. 2. **Update** endpoints to use `/devices/` structure. 3. **Refactor** request payloads to align with new formats. 4. **Test** new APIs for individual, bulk, and group configurations. 5. **Monitor** for deprecated API usage and plan for removal. For detailed information on Aware APIs, see the respective sections in the [documentation](https://docs.na-rpb.demo.aware.qualcomm.com/). For further help, contact the [Aware support](https://mysupport.qualcomm.com/aware/s/) forum. ### Known limitations - Trackers in the NOT\_SET status can't have configurations updated or shipments assigned. Contact [Aware support](https://mysupport.qualcomm.com/aware/s/) for assistance. - To use Larger Reporting Intervals (for example, 24 hours) with the MCD feature, set the MCD stationary reporting to 24 hours. - The Fall Distance information displayed in Fall Alerts is currently being improved, with more accurate distance estimation expected in the next upgrade. - For optimal performance on the Aware service portal and to avoid potential issues related to WebGL, it is recommended to use the latest version of Google Chrome (version 126.0 or higher). - The *OnCharge/OffCharge* feature is currently available only for the QTS110 device. - The outer geofence radius selection for creating shipments isn't ready for commercial use cases. - The *conditionalConfiguration* feature in tracker APIs is available only on cloud with limited device functionality. For further help or to report issues, reach out to the [Aware support](https://mysupport.qualcomm.com/aware/s/) team. ### Technical support If you have any questions or need help regarding the latest features, our support team is here to help! For help, create a support request in the [Aware support](https://mysupport.qualcomm.com/aware/s/) forum. ## Version: GA 2.9.0 Source: [https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html](https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html) This page outlines the changes and enhancements introduced in the GA 2.9.0 release of the Aware Cloud Platform. This release focuses on simplifying onboarding workflows for module‑based devices and improving platform transparency, reducing operational overhead for customers and partners while enhancing visibility into the running Aware platform version. **Release Date:** May 5, 2026 ### New features - **Aware Base Connector SDK for QCX217** - This release introduces enhancements to the Aware Base Connector (BC) SDK for QCX217, with a focus on improving onboarding efficiency and control. - **Low‑Touch and Medium‑Touch Onboarding Improvements** - The onboarding workflows for the Base Connector SDK have been enhanced to simplify device setup and reduce onboarding effort for both customers and partners: - **Low‑Touch Onboarding:** Devices automatically self‑onboard when powered on for the first time, requiring minimal manual intervention and enabling the fastest path to provisioning. - **Medium‑Touch Onboarding:** Partial provisioning can be performed ahead of time, providing increased control, earlier inventory visibility, and greater operational flexibility during manufacturing or staging. These improvements streamline provisioning flows, reduce manual steps, and make onboarding more scalable across high‑volume deployments. - **Platform Version Visibility** - With GA 2.9.0, the Aware platform version is now explicitly exposed to customers: - The GA software version is displayed in the Aware Service Portal - The platform version is also exposed through Aware APIs This enhancement enables customers and partners to identify the Aware platform version they're operating on, supporting easier troubleshooting, compliance verification, and integration alignment. ### Aware API enhancements To support scalable and maintainable device management, the legacy `/trackers/` API structure is transitioning to a more unified and flexible `/devices/` API framework. This migration is designed to simplify configuration workflows across individual devices, groups, and asset types, while reducing operational overhead. By adopting the proposed APIs, developers can ensure consistent configuration practices, streamline bulk operations, and improve the overall reliability and scalability of device management systems. The following section outlines key changes and provides actionable guidance to facilitate a smooth transition. **Migration Guide** This migration aims to: - Streamline device configuration management. - Enable consistent configuration across individual devices, groups, and asset types. - Improve maintainability and scalability of configuration workflows. - Reduce operational overhead through standardized and simplified APIs. Table : Individual Device Configuration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Individual Device Configuration | `GET /v1/trackers/{serialNumber}/config*` | `GET
/v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response
includes `deviceConfiguration` and
`pendingDeviceConfiguration`. | | Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH
/v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for
partial updates. | | New endpoint | – | `POST
/v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset
type. | Table : Bulk Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Bulk Configuration Update | `POST
/v1/devices/bulk/configuration/update*` | `POST
/v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in
bulk. | | Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on
`assetTypeId`. | | Bulk Tracker Config | `POST /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better
scalability. | Table : Group Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under
`/devices/groups/`. | | Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by
`assetTypeId`. | \* These APIs have been marked as "TO BE DEPRECATED" starting with the 2.4.0 release. Please migrate to the recommended alternatives. For assistance, reach out to the [Aware support](https://mysupport.qualcomm.com/aware/s/) team. **Request and response changes** Request enhancements: - **Standardized paths**: All new APIs use `/devices/` instead of `/trackers/`. - **Asset Type Support**: New APIs allow applying configurations by `assetTypeId`. - **PATCH over PUT**: Use `PATCH` for partial updates to avoid overwriting unchanged fields. Response improvements: - **Structured JSON**: Responses now return `pendingDeviceConfiguration` in addition to the current configuration on the device. **Notes and best practices** - **Bulk Limits**: All bulk APIs should enforce a configurable limit (default: 50 devices per request). - **Deprecation Awareness**: Avoid using deprecated `/trackers/` endpoints in new implementations. - **Consistency**: Use assetType-based APIs for scalable and consistent configuration across device types. The legacy APIs marked as TO BE DEPRECATED will continue to be available during the transition period to support a smooth migration from the `/trackers/` framework to the new `/devices/` structure. This ensures backward compatibility and allows teams to update their integrations incrementally. Importantly, there were no breaking changes introduced, so existing implementations will continue to function as expected while teams adopt the new APIs. **Action items for developers** 1. **Audit** existing usage of `/trackers/` APIs in your services. 2. **Update** endpoints to use `/devices/` structure. 3. **Refactor** request payloads to align with new formats. 4. **Test** new APIs for individual, bulk, and group configurations. 5. **Monitor** for deprecated API usage and plan for removal. For detailed information on Aware APIs, see the respective sections in the [documentation](https://docs.na-rpb.demo.aware.qualcomm.com/). For further help, contact the [Aware support](https://mysupport.qualcomm.com/aware/s/) forum. ## Version: GA 2.8.0 Source: [https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html](https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html) This page outlines the changes and enhancements introduced in the GA 2.8.0 release of the Aware Cloud Platform. This release focuses on expanding device integration capabilities, improving service lifecycle control, and strengthening event‑driven observability. Key highlights include enhancements to the Aware Base Connector SDK for QCX216 and QCX217, new APIs for managing Aware service lifecycle on module‑based devices, and improved multi‑tenant visibility through enriched API responses. Collectively, these updates simplify device onboarding, enable finer operational control, and improve realtime monitoring and automation for Aware‑enabled deployments. **Release Date:** February 26, 2026 ### New features - **Aware Base Connector SDK for QCX216 and QCX217** - With this release, Aware introduces the Base Connector (BC) SDK for QCX216 and QCX217 platforms. The SDK now supports opaque data exchange in both Device‑to‑Cloud (D2C) and Cloud‑to‑Device (C2D) directions, enabling flexible data transfer without imposing schema constraints. More details [here](https://docs.qualcomm.com/doc/80-70215-13/80-70215-13_REV_AA_Qualcomm_Base_Connector_SDK_Integration_Guide.pdf). - New service lifecycle APIs allow tighter integration with Aware Cloud APIs, enabling customers to manage device services more effectively within their application workflows. - **Realtime Device Status and Event Integrations**: The BC SDK enhancements also introduce heartbeat signaling and webhook capabilities, enabling near realtime device status monitoring and event‑driven integrations with external systems. These capabilities allow customers to detect device availability changes and trigger automated workflows based on device events. For more information, reach out to the [Aware support](https://mysupport.qualcomm.com/aware/s/) team. - **Aware API enhancements** - **Service Lifecycle Control APIs**: This release adds new Aware Cloud APIs that allow customers to start and stop the Aware service on QCX217‑based Aware modules. These APIs provide greater flexibility for customers building devices with Aware modules, enabling them to control service activation based on operational, provisioning, or lifecycle requirements. - **Improved Multi-tenant Context Visibility**: Aware APIs now return parent‑tenant context during device type promotion and module movement operations. This enhancement improves navigation and visibility for multi‑tenant users managing devices across environments, helping reduce ambiguity and simplify administrative workflows in complex tenant hierarchies. ### Aware API enhancements To support scalable and maintainable device management, the legacy `/trackers/` API structure is transitioning to a more unified and flexible `/devices/` API framework. This migration is designed to simplify configuration workflows across individual devices, groups, and asset types, while reducing operational overhead. By adopting the proposed APIs, developers can ensure consistent configuration practices, streamline bulk operations, and improve the overall reliability and scalability of device management systems. The following section outlines key changes and provides actionable guidance to facilitate a smooth transition. **Migration Guide** This migration aims to: - Streamline device configuration management. - Enable consistent configuration across individual devices, groups, and asset types. - Improve maintainability and scalability of configuration workflows. - Reduce operational overhead through standardized and simplified APIs. Table : Individual Device Configuration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Individual Device Configuration | `GET /v1/trackers/{serialNumber}/config*` | `GET
/v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response
includes `deviceConfiguration` and
`pendingDeviceConfiguration`. | | Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH
/v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for
partial updates. | | New endpoint | – | `POST
/v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset
type. | Table : Bulk Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Bulk Configuration Update | `POST
/v1/devices/bulk/configuration/update*` | `POST
/v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in
bulk. | | Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on
`assetTypeId`. | | Bulk Tracker Config | `POST /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better
scalability. | Table : Group Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under
`/devices/groups/`. | | Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by
`assetTypeId`. | \* These APIs have been marked as "TO BE DEPRECATED" starting with the 2.4.0 release. Please migrate to the recommended alternatives. For assistance, reach out to the [Aware support](https://mysupport.qualcomm.com/aware/s/) team. **Request and response changes** Request enhancements: - **Standardized paths**: All new APIs use `/devices/` instead of `/trackers/`. - **Asset Type Support**: New APIs allow applying configurations by `assetTypeId`. - **PATCH over PUT**: Use `PATCH` for partial updates to avoid overwriting unchanged fields. Response improvements: - **Structured JSON**: Responses now return `pendingDeviceConfiguration` in addition to the current configuration on the device. **Notes and best practices** - **Bulk Limits**: All bulk APIs should enforce a configurable limit (default: 50 devices per request). - **Deprecation Awareness**: Avoid using deprecated `/trackers/` endpoints in new implementations. - **Consistency**: Use assetType-based APIs for scalable and consistent configuration across device types. The legacy APIs marked as TO BE DEPRECATED will continue to be available during the transition period to support a smooth migration from the `/trackers/` framework to the new `/devices/` structure. This ensures backward compatibility and allows teams to update their integrations incrementally. Importantly, there were no breaking changes introduced in GA 2.4.0, so existing implementations will continue to function as expected while teams adopt the new APIs. **Action items for developers** 1. **Audit** existing usage of `/trackers/` APIs in your services. 2. **Update** endpoints to use `/devices/` structure. 3. **Refactor** request payloads to align with new formats. 4. **Test** new APIs for individual, bulk, and group configurations. 5. **Monitor** for deprecated API usage and plan for removal. For detailed information on Aware APIs, see the respective sections in the [documentation](https://docs.na-rpb.demo.aware.qualcomm.com/). For further help, contact the [Aware support](https://mysupport.qualcomm.com/aware/s/) forum. ## Version: GA 2.7.0 Source: [https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html](https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html) This page outlines the changes and enhancements made in the GA 2.7.0 release of the Aware Cloud Platform. This release introduces the latest advancements in Aware, delivering powerful new capabilities that simplify device onboarding, enhance firmware lifecycle management, and strengthen data reliability across Aware‑enabled module‑based devices. This release focuses on reducing operational effort for OEMs, improving manageability at scale, and enabling more robust integrations for developers. With streamlined provisioning flows, integrated FOTA support, and resilient webhook replay mechanisms, the Aware platform continues to evolve to meet the growing needs of connected‑device ecosystems. **Release Date:** December 18, 2025 ### New features **Enhancements to Aware enabled module-based devices** - **Simplified Onboarding** Device OEMs can now use QSPR for complete device provisioning and onboarding, eliminating the need for manual registration steps previously performed by Module OEMs. This significantly: - Reduces onboarding complexity - Improves operational efficiency - Speeds up time‑to‑market for both Module and Device OEMs With this simplified flow, the entire onboarding process becomes more scalable, automated, and easier to integrate into OEM manufacturing workflows. - **FOTA‑as‑a‑Service** The release introduces firmware‑over‑the‑air (FOTA) service support for QCX217‑based Aware Module devices. Through the Aware Service Dashboard, you can now: - Create and schedule firmware‑upgrade campaigns - Manage device updates at scale - Monitor upgrade progress and status in real time This integrated FOTA capability ensures seamless firmware lifecycle management without requiring custom tooling. - **Webhook Data Replay** Developers can now reliably redeliver missed or failed webhook notifications using the new Webhook Data Replay feature. Available through both the Service Portal and Aware API, this feature allows: - Replay job creation for missed notifications - Retrieval of historical telemetry or location events - Filter‑based replay using time ranges or event sequence numbers This ensures more robust downstream integrations and improved data consistency for applications relying on webhook‑based event ingestion. ### Aware API enhancements To support scalable and maintainable device management, the legacy `/trackers/` API structure is transitioning to a more unified and flexible `/devices/` API framework. This migration is designed to simplify configuration workflows across individual devices, groups, and asset types, while reducing operational overhead. By adopting the proposed APIs, developers can ensure consistent configuration practices, streamline bulk operations, and improve the overall reliability and scalability of device management systems. The following section outlines key changes and provides actionable guidance to facilitate a smooth transition. **Migration Guide** This migration aims to: - Streamline device configuration management. - Enable consistent configuration across individual devices, groups, and asset types. - Improve maintainability and scalability of configuration workflows. - Reduce operational overhead through standardized and simplified APIs. Table : Individual Device Configuration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Individual Device Configuration | `GET /v1/trackers/{serialNumber}/config*` | `GET
/v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response
includes `deviceConfiguration` and
`pendingDeviceConfiguration`. | | Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH
/v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for
partial updates. | | New endpoint | – | `POST
/v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset
type. | Table : Bulk Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Bulk Configuration Update | `POST
/v1/devices/bulk/configuration/update*` | `POST
/v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in
bulk. | | Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on
`assetTypeId`. | | Bulk Tracker Config | `POST /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better
scalability. | Table : Group Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under
`/devices/groups/`. | | Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by
`assetTypeId`. | \* These APIs have been marked as "TO BE DEPRECATED" starting with the 2.4.0 release. Please migrate to the recommended alternatives. For assistance, reach out to the [Aware support](https://mysupport.qualcomm.com/aware/s/) team. **Request and response changes** Request enhancements: - **Standardized paths**: All new APIs use `/devices/` instead of `/trackers/`. - **Asset Type Support**: New APIs allow applying configurations by `assetTypeId`. - **PATCH over PUT**: Use `PATCH` for partial updates to avoid overwriting unchanged fields. Response improvements: - **Structured JSON**: Responses now return `pendingDeviceConfiguration` in addition to the current configuration on the device. **Notes and best practices** - **Bulk Limits**: All bulk APIs should enforce a configurable limit (default: 50 devices per request). - **Deprecation Awareness**: Avoid using deprecated `/trackers/` endpoints in new implementations. - **Consistency**: Use assetType-based APIs for scalable and consistent configuration across device types. The legacy APIs marked as TO BE DEPRECATED will continue to be available during the transition period to support a smooth migration from the `/trackers/` framework to the new `/devices/` structure. This ensures backward compatibility and allows teams to update their integrations incrementally. Importantly, there were no breaking changes introduced in GA 2.4.0, so existing implementations will continue to function as expected while teams adopt the new APIs. **Action items for developers** 1. **Audit** existing usage of `/trackers/` APIs in your services. 2. **Update** endpoints to use `/devices/` structure. 3. **Refactor** request payloads to align with new formats. 4. **Test** new APIs for individual, bulk, and group configurations. 5. **Monitor** for deprecated API usage and plan for removal. For detailed information on Aware APIs, see the respective sections in the [documentation](https://docs.na-rpb.demo.aware.qualcomm.com/). For further help, contact the [Aware support](https://mysupport.qualcomm.com/aware/s/) forum. ## Version: GA 2.6.1 Source: [https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html](https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html) This page outlines the changes and enhancements made in the GA 2.6.1 release of the Aware Cloud Platform. This release focuses on enhancing device observability, telemetry reporting, and API usability. Notably, it introduces support for device health monitoring, configurable battery alerts, and frequent telemetry updates for Aware-enabled modules. It also adds webhook improvements, interactive API documentation, and a trial dashboard for Location SDK insights—streamlining diagnostics, automation, and integration workflows for enterprise IoT deployments. **Release Date:** November 20, 2025 ### New features - **Aware Observability** - With this release, Aware supports device health observability, public APIs, insights generation, and a visualization dashboard (Trial only) for the Location SDK. The Location SDK is a separate standalone SDK. For more information, reach out to the [Aware support](https://mysupport.qualcomm.com/aware/s/) team. - **Enhancements to Aware enabled module-based devices** - **Continuous Reporting**: Devices based on Aware enabled module, can now report their location and telemetry data more frequently (at 3-minute reporting frequency). This feature enables customers to track/monitor their custom devices closely. Note that less 3-minute reporting will be coming soon. - **Battery Threshold Controls**: Introduces configurable battery alert thresholds for Aware enabled module-based devices via the Service Dashboard. - **Aware API enhancements** - **Webhook enhancements**: Device Serial Number (DSN) is now included in webhook payloads for improved traceability. - **Improved API documentation**: Aware Cloud API Reference now includes interactive examples and detailed error code explanations. ### Aware API enhancements To support scalable and maintainable device management, we're transitioning from the legacy `/trackers/` API structure to a more unified and flexible `/devices/` API framework. This migration is designed to simplify configuration workflows across individual devices, groups, and asset types, while reducing operational overhead. By adopting the proposed APIs, developers can ensure consistent configuration practices, streamline bulk operations, and improve the overall reliability and scalability of device management systems. The following section outlines key changes and provides actionable guidance to facilitate a smooth transition. **Migration Guide** This migration aims to: - Streamline device configuration management. - Enable consistent configuration across individual devices, groups, and asset types. - Improve maintainability and scalability of configuration workflows. - Reduce operational overhead through standardized and simplified APIs. Table : Individual Device Configuration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Individual Device Configuration | `GET /v1/trackers/{serialNumber}/config*` | `GET
/v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response
includes `deviceConfiguration` and
`pendingDeviceConfiguration`. | | Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH
/v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for
partial updates. | | New endpoint | – | `POST
/v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset
type. | Table : Bulk Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Bulk Configuration Update | `POST
/v1/devices/bulk/configuration/update*` | `POST
/v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in
bulk. | | Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on
`assetTypeId`. | | Bulk Tracker Config | `POST /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better
scalability. | Table : Group Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under
`/devices/groups/`. | | Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by
`assetTypeId`. | \* These APIs have been marked as "TO BE DEPRECATED" starting with the 2.4.0 release. Please migrate to the recommended alternatives. For assistance, reach out to the [Aware support](https://mysupport.qualcomm.com/aware/s/) team. **Request and response changes** Request enhancements: - **Standardized paths**: All new APIs use `/devices/` instead of `/trackers/`. - **Asset Type Support**: New APIs allow applying configurations by `assetTypeId`. - **PATCH over PUT**: Use `PATCH` for partial updates to avoid overwriting unchanged fields. Response improvements: - **Structured JSON**: Responses now return `pendingDeviceConfiguration` in addition to the current configuration on the device. **Notes and best practices** - **Bulk Limits**: All bulk APIs should enforce a configurable limit (default: 50 devices per request). - **Deprecation Awareness**: Avoid using deprecated `/trackers/` endpoints in new implementations. - **Consistency**: Use assetType-based APIs for scalable and consistent configuration across device types. The legacy APIs marked as TO BE DEPRECATED will continue to be available during the transition period to support a smooth migration from the `/trackers/` framework to the new `/devices/` structure. This ensures backward compatibility and allows teams to update their integrations incrementally. Importantly, there were no breaking changes introduced in GA 2.4.0, so existing implementations will continue to function as expected while teams adopt the new APIs. **Action items for developers** 1. **Audit** existing usage of `/trackers/` APIs in your services. 2. **Update** endpoints to use `/devices/` structure. 3. **Refactor** request payloads to align with new formats. 4. **Test** new APIs for individual, bulk, and group configurations. 5. **Monitor** for deprecated API usage and plan for removal. For detailed information on Aware APIs, see the respective sections in the [documentation](https://docs.na-rpb.demo.aware.qualcomm.com/). For further help, contact the [Aware support](https://mysupport.qualcomm.com/aware/s/) forum. ## Version: GA 2.6.0 Source: [https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html](https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html) This page outlines the changes and enhancements made in the GA 2.6.0 release of the Aware Cloud Platform. This release focuses on enhancing device observability, telemetry reporting, and API usability. Notably, it introduces support for device health monitoring, configurable battery alerts, and frequent telemetry updates for Aware-enabled modules. It also adds webhook improvements, interactive API documentation, and a trial dashboard for Location SDK insights—streamlining diagnostics, automation, and integration workflows for enterprise IoT deployments. **Release Date:** November 6, 2025 ### New features - **Aware Observability** - With this release, Aware supports device health observability, public APIs, insights generation, and a visualization dashboard (Trial only) for the Location SDK. The Location SDK is a separate standalone SDK. For more information, reach out to the [Aware support](https://mysupport.qualcomm.com/aware/s/) team. - **Enhancements to Aware enabled module-based devices** - **Continuous Reporting**: Devices based on Aware enabled module, can now report their location and telemetry data more frequently (at 3-minute reporting frequency). This feature enables customers to track/monitor their custom devices closely. Note that less 3-minute reporting will be coming soon. - **Battery Threshold Controls**: Introduces configurable battery alert thresholds for Aware enabled module-based devices through the Service Dashboard. - **Aware API enhancements** - **Webhook enhancements**: Device Serial Number (DSN) is now included in webhook payloads for improved traceability. - **Improved API documentation**: Aware Cloud API Reference now includes interactive examples and detailed error code explanations. ### Aware API enhancements To support scalable and maintainable device management, the legacy `/trackers/` API structure is transitioning to a more unified and flexible `/devices/` API framework. This migration is designed to simplify configuration workflows across individual devices, groups, and asset types, while reducing operational overhead. By adopting the proposed APIs, developers can ensure consistent configuration practices, streamline bulk operations, and improve the overall reliability and scalability of device management systems. The following section outlines key changes and provides actionable guidance to facilitate a smooth transition. **Migration Guide** This migration aims to: - Streamline device configuration management. - Enable consistent configuration across individual devices, groups, and asset types. - Improve maintainability and scalability of configuration workflows. - Reduce operational overhead through standardized and simplified APIs. Table : Individual Device Configuration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Individual Device Configuration | `GET
/v1/trackers/{serialNumber}/config*` | `GET
/v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response
includes `deviceConfiguration` and
`pendingDeviceConfiguration`. | | Update Device Configuration | `PUT
/v1/trackers/{serialNumber}/config*` | `PATCH
/v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH`
for partial updates. | | New endpoint | – | `POST
/v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset
type. | Table : Bulk Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Bulk Configuration Update | `POST
/v1/devices/bulk/configuration/update*` | `POST
/v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in
bulk. | | Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on
`assetTypeId`. | | Bulk Tracker Config | `POST /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better
scalability. | Table : Group Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under
`/devices/groups/`. | | Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by
`assetTypeId`. | \* These APIs have been marked as "TO BE DEPRECATED" starting with the 2.4.0 release. Please migrate to the recommended alternatives. For assistance, reach out to the [Aware support](https://mysupport.qualcomm.com/aware/s/) team. **Request and response changes** Request enhancements: - **Standardized paths**: All new APIs use `/devices/` instead of `/trackers/`. - **Asset Type Support**: New APIs allow applying configurations by `assetTypeId`. - **PATCH over PUT**: Use `PATCH` for partial updates to avoid overwriting unchanged fields. Response improvements: - **Structured JSON**: Responses now return `pendingDeviceConfiguration` in addition to the current configuration on the device. **Notes and best practices** - **Bulk Limits**: All bulk APIs should enforce a configurable limit (default: 50 devices per request). - **Deprecation Awareness**: Avoid using deprecated `/trackers/` endpoints in new implementations. - **Consistency**: Use assetType-based APIs for scalable and consistent configuration across device types. The legacy APIs marked as TO BE DEPRECATED will continue to be available during the transition period to support a smooth migration from the `/trackers/` framework to the new `/devices/` structure. This ensures backward compatibility and allows teams to update their integrations incrementally. Importantly, there were no breaking changes introduced in GA 2.4.0, so existing implementations will continue to function as expected while teams adopt the new APIs. **Action items for developers** 1. **Audit** existing usage of `/trackers/` APIs in your services. 2. **Update** endpoints to use `/devices/` structure. 3. **Refactor** request payloads to align with new formats. 4. **Test** new APIs for individual, bulk, and group configurations. 5. **Monitor** for deprecated API usage and plan for removal. For detailed information on Aware APIs, see the respective sections in the [documentation](https://docs.na-rpb.demo.aware.qualcomm.com/). For further help, contact the [Aware support](https://mysupport.qualcomm.com/aware/s/) forum. ## Version: GA 2.5.0 Source: [https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html](https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html) This page outlines the changes and enhancements made in the GA 2.5.0 release of the Aware Cloud Platform. This release focuses on improving device onboarding, cross-environment workflows, and API-driven automation. Notably, it introduces support for QCX217 device provisioning, environment switching, and new APIs for light exposure monitoring and asset deletion. These updates are designed to streamline development, testing, and lifecycle management for enterprise IoT deployments. **Release Date:** September 30, 2025 ### New features - **Aware Edge SDK and Aware Cloud Enhancements** - **Custom Product Type Promotion:** - Developers can now promote custom product type definitions from a customer's Aware DEMO account to their Aware PROD account. - This enables seamless migration of development configurations to production environments, reducing duplication and manual effort. - **Device movement between environments:** - Devices can now be moved between DEMO and PROD accounts, and vice versa. - This facilitates flexible testing and deployment workflows, and is especially useful for staging and validation scenarios. - **Improved Data management** - With the new asset deletion capabilities, developers gain greater control over device data, allowing for cleaner lifecycle management, especially during reprovisioning or environment transitions. ### Aware API enhancements To support scalable and maintainable device management, we're transitioning from the legacy `/trackers/` API structure to a more unified and flexible `/devices/` API framework. This migration is designed to simplify configuration workflows across individual devices, groups, and asset types, while reducing operational overhead. By adopting the proposed APIs, developers can ensure consistent configuration practices, streamline bulk operations, and improve the overall reliability and scalability of device management systems. The following section outlines key changes and provides actionable guidance to facilitate a smooth transition. **Migration Guide** This migration aims to: - Streamline device configuration management. - Enable consistent configuration across individual devices, groups, and asset types. - Improve maintainability and scalability of configuration workflows. - Reduce operational overhead through standardized and simplified APIs. Table : Individual Device Configuration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Individual Device Configuration | `GET /v1/trackers/{serialNumber}/config*` | `GET
/v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response
includes `deviceConfiguration` and
`pendingDeviceConfiguration`. | | Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH
/v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for
partial updates. | | New endpoint | – | `POST
/v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset
type. | \* Will be marked as *TO BE DEPRECATED* in the 2.4.0 release. Table : Bulk Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Bulk Configuration Update | `POST
/v1/devices/bulk/configuration/update*` | `POST
/v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in
bulk. | | Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on
`assetTypeId`. | | Bulk Tracker Config | `POST /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better
scalability. | \* Will be marked as *TO BE DEPRECATED* in the 2.4.0 release. Table : Group Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under
`/devices/groups/`. | | Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by
`assetTypeId`. | **Request and response changes** Request enhancements: - **Standardized paths**: All new APIs use `/devices/` instead of `/trackers/`. - **Asset Type Support**: New APIs allow applying configurations by `assetTypeId`. - **PATCH over PUT**: Use `PATCH` for partial updates to avoid overwriting unchanged fields. Response improvements: - **Structured JSON**: Responses now return `pendingDeviceConfiguration` in addition to the current configuration on the device. **Notes and best practices** - **Bulk Limits**: All bulk APIs should enforce a configurable limit (default: 50 devices per request). - **Deprecation Awareness**: Avoid using deprecated `/trackers/` endpoints in new implementations. - **Consistency**: Use assetType-based APIs for scalable and consistent configuration across device types. The legacy APIs marked as TO BE DEPRECATED will continue to be available during the transition period to support a smooth migration from the `/trackers/` framework to the new `/devices/` structure. This ensures backward compatibility and allows teams to update their integrations incrementally. Importantly, there were no breaking changes introduced in GA 2.4.0, so existing implementations will continue to function as expected while teams adopt the new APIs. **Action items for developers** 1. **Audit** existing usage of `/trackers/` APIs in your services. 2. **Update** endpoints to use `/devices/` structure. 3. **Refactor** request payloads to align with new formats. 4. **Test** new APIs for individual, bulk, and group configurations. 5. **Monitor** for deprecated API usage and plan for removal. ## Version: GA 2.4.0 Source: [https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html](https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html) This page outlines the changes and enhancements made in the GA 2.4.0 release of the Aware Cloud Platform. This release focuses on improving cross-environment workflows, device flexibility, and API-driven configuration management. Notably, it introduces Bring Your Own Connectivity (BYOC) support for QTS112 devices, empowering customers with greater control over their connectivity stack. These updates are designed to streamline development, testing, and deployment processes for enterprise IoT solutions. **Release Date:** August 5, 2025 ### New features - **Aware Edge SDK and Aware Cloud Enhancements** - **Custom Product Type Promotion:** - Developers can now promote custom product type definitions from a customer's Aware DEMO account to their Aware PROD account. - This enables seamless migration of development configurations to production environments, reducing duplication and manual effort. - **Device movement between environments:** - Devices can now be moved between DEMO and PROD accounts, and vice versa. - This facilitates flexible testing and deployment workflows, and is especially useful for staging and validation scenarios. - **Bring Your Own Connectivity (BYOC) Support** - **Third-Party Connectivity for QTS112:** - Aware now supports service enablement on QTS112 devices using third-party connectivity. - This offers customers the freedom to use their preferred connectivity providers, enhancing deployment flexibility and cost control. - **Aware API Enhancements** - **Device Configuration Management:** - New API endpoints let you update settings for individual devices or apply changes to many devices at once. - This simplifies large-scale device management and reduces operational overhead. - **Group Configuration Management:** - You can now create and update configuration profiles for device groups using the API. - This enables consistent configuration across device groups, improving maintainability and scalability. - **Hosted API Schema:** - A new Download Schema option is now available under each API family on the [OpenAPI Specifications](https://docs.na-rpb.demo.aware.qualcomm.com/) page, enabling easy access to hosted API schemas. ### Aware API enhancements To support scalable and maintainable device management, the legacy `/trackers/` API structure is transitioning to a more unified and flexible `/devices/` API framework. This migration is designed to simplify configuration workflows across individual devices, groups, and asset types, while reducing operational overhead. By adopting the proposed APIs, developers can ensure consistent configuration practices, streamline bulk operations, and improve the overall reliability and scalability of device management systems. The following section outlines key changes and provides actionable guidance to facilitate a smooth transition. **Migration Guide** This migration aims to: - Streamline device configuration management. - Enable consistent configuration across individual devices, groups, and asset types. - Improve maintainability and scalability of configuration workflows. - Reduce operational overhead through standardized and simplified APIs. Table : Individual Device Configuration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Individual Device Configuration | `GET /v1/trackers/{serialNumber}/config*` | `GET
/v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response
includes `deviceConfiguration` and
`pendingDeviceConfiguration`. | | Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH
/v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for
partial updates. | | New endpoint | – | `POST
/v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset
type. | \* Will be marked as *TO BE DEPRECATED* in the 2.4.0 release. Table : Bulk Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Bulk Configuration Update | `POST
/v1/devices/bulk/configuration/update*` | `POST
/v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in
bulk. | | Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on
`assetTypeId`. | | Bulk Tracker Config | `POST /v1/trackers/bulk/config`
*(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better
scalability. | \* Will be marked as *TO BE DEPRECATED* in the 2.4.0 release. Table : Group Configuration API migration | Category | Current API | Proposed API | Key changes | | --- | --- | --- | --- | | Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under
`/devices/groups/`. | | Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`
*(TO BE DEPRECATED)* | `POST
/v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by
`assetTypeId`. | **Request and response changes** Request enhancements: - **Standardized paths**: All new APIs use `/devices/` instead of `/trackers/`. - **Asset Type Support**: New APIs allow applying configurations by `assetTypeId`. - **PATCH over PUT**: Use `PATCH` for partial updates to avoid overwriting unchanged fields. Response improvements: - **Structured JSON**: Responses now return `pendingDeviceConfiguration` in addition to the current configuration on the device. **Notes and best practices** - **Bulk Limits**: All bulk APIs should enforce a configurable limit (default: 50 devices per request). - **Deprecation Awareness**: Avoid using deprecated `/trackers/` endpoints in new implementations. - **Consistency**: Use assetType-based APIs for scalable and consistent configuration across device types. The legacy APIs marked as TO BE DEPRECATED will continue to be available during the transition period to support a smooth migration from the `/trackers/` framework to the new `/devices/` structure. This ensures backward compatibility and allows teams to update their integrations incrementally. Importantly, there were no breaking changes introduced in GA 2.4.0, so existing implementations will continue to function as expected while teams adopt the new APIs. **Action items for developers** 1. **Audit** existing usage of `/trackers/` APIs in your services. 2. **Update** endpoints to use `/devices/` structure. 3. **Refactor** request payloads to align with new formats. 4. **Test** new APIs for individual, bulk, and group configurations. 5. **Monitor** for deprecated API usage and plan for removal. ## Version: GA 2.3.0 Source: [https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html](https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html) This page outlines the changes and enhancements made in the GA 2.3.0 release of the Aware Cloud Platform. This release of the Aware Developer Workspace brings a host of new features and enhancements to the Aware platform. This release is designed to improve performance, streamline operations, and enhance compatibility with cloud services. **Release Date:** July 3, 2025 ### New features - **Aware Edge SDK and Aware Cloud Enhancements:** To enable the QCX217 Aware-enabled modules, coordinated enhancements are being delivered across both the Aware Cloud and Aware Edge SDK. - **Cloud Enhancements:** - Improvements to QCX217 modules' onboarding process. - **SDK Enhancements:** - Improved data backup mechanisms to ensure resilience and reliability. - Streamlined configuration file handling for easier maintenance. ### Aware API enhancements The Aware APIs have been updated with enhancements to existing functionalities, ensuring no breaking changes to backward compatibility. The light exposure configuration settings now has the following change: the field previously known as `antiTheftSingleshotThreshold` has been renamed to `lightThresholdInADC`. Note that this field is optional and specifically targeted for the Aware module QCX217. **Affected endpoints** - **Devices:** - `POST /v1/devices/bulk/configuration/update` - **Trackers:** - `POST /v1/trackers/bulk/config` (deprecated) - `POST /v1/trackers/bulk/{groupId}/config` (deprecated) - `PUT /v1/trackers/{serialNumber}/config` - `GET /v1/trackers/{serialNumber}/config` - **Asset Types:** - `GET /v1/assettypes/{id}` - `PUT /v1/assettypes/{id}` - `PATCH /v1/assettypes/{id}` - `GET /v1/assettypes` - `POST /v1/assettypes` ## Version: GA 2.2.0 Source: [https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html](https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html) This page outlines the changes and enhancements made in the GA 2.2.0 release of the Aware Cloud Platform. This release of the Aware Developer Workspace brings a host of new features and enhancements to the Aware platform. This release is designed to improve your development experience and provide greater control over device management and data access. **Release Date:** June 9, 2025 ### New features - **Updates to Aware Developer Workspace:** - Notifications upon device/module onboarding. - Telemetry data queries by Device Serial Number (DSN). - Enhanced functionality, user experience, and control over device management and data access. - **Enhancements to Subtenancy Feature:** - Subtenants can access Aware APIs for device data retrieval using tenant-provided client credentials. - Tenants must contact Aware support to obtain client credentials for newly created subtenants. - Subtenants can now use both Aware APIs and Webhooks to retrieve telemetry data. ### Aware API enhancements The Aware APIs have been updated with enhancements to existing functionalities, ensuring no breaking changes to backward compatibility. The light exposure settings now support five types: `continuous`, `onetime`, `singleAlert`, `alertUponAnyLightEvent`, and `alertEveryLightTransition`. These updates impact several endpoints, including those related to devices, trackers, and asset types. Developers are advised to implement and test these changes accordingly. **Changes to light exposure** Light exposure now has 5 options supported for the `type` field: - `continuous` - `onetime` - `singleAlert` - `alertUponAnyLightEvent` - `alertEveryLightTransition` Example: { "lightExposure": { "isEnabled": true, "type": "continuous / onetime / singleAlert / alertUponAnyLightEvent / alertEveryLightTransition", "antiTheftSingleshotThreshold": 10 } }Copy to clipboard For turnkey devices, the light exposure type can be set to either `continuous` or `onetime`. For custom devices, you can choose `singleAlert`, `alertUponAnyLightEvent`, or `alertEveryLightTransition`. **Affected endpoints** - **Devices:** - `POST /v1/devices/bulk/configuration/update` - **Trackers:** - `POST /v1/trackers/bulk/config` (deprecated) - `POST /v1/trackers/bulk/{groupId}/config` (deprecated) - `PUT /v1/trackers/{serialNumber}/config` - `GET /v1/trackers/{serialNumber}/config` - **Asset Types:** - `GET /v1/assettypes/{id}` - `PUT /v1/assettypes/{id}` - `PATCH /v1/assettypes/{id}` - `GET /v1/assettypes` - `POST /v1/assettypes` ## Version: GA 2.1.0 Source: [https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html](https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html) This document outlines the changes and enhancements made in the GA 2.1.0 release of the Aware Cloud Platform. This release of the Aware Developer Portal brings significant improvements to collaboration, device management, and integration, ensuring a more flexible and efficient user experience. This update includes new features, API enhancements, and important changes to the Aware Open offering, including the license management. **Release Date:** May 5, 2025 ### New features - **Aware Developer Portal Enhancements:** Includes multi-developer access for Aware-enabled module design, support for temperature sensors, and a lightweight activity log for debugging custom devices. Additionally, it introduces API support for custom devices and updates to device configuration processes to ensure synchronization between devices and cloud. This feature is only available in the DEMO environment. - **Subtenancy:** Includes enhanced tenant user management, allowing users to work together effectively, and the ability to move devices between subtenants for better flexibility. Additionally, it introduces robust APIs for subtenant management and user management, ensuring seamless integration and control. - **Aware License Management:** Introduces per-device licensing for software and hardware features on Qualcomm Root-of-Trust devices, with a focus on the RFID feature. This feature allows precise control over license grant and revocation directly from the device, ensuring flexibility and efficiency. - **Aware Basic Observability:** Enhances Aware Open by supporting external identifiers like IMEI and Mac Address, enabling more flexible and efficient device management. ### Aware API enhancements - **Cloud Integration Enhancements for Aware Enabled Modules:**Introduces several new API endpoints to support custom devices (built using Aware Edge SDK) and tracker service changes, including configuration updates for battery and theft. - **Trackers** - `GET /v1/trackers/{serialNumber}/config` - `PUT /v1/trackers/{serialNumber}/config` - `GET /v1/trackers/{serialNumber}/status` - `GET /v1/trackers/{serialNumber}/audit` - `GET /v1/trackers/{serialNumber}/alerts` - **Devices** - `POST /v1/devices/bulk/configuration/update` - `POST /v1/trackers/bulk/config` (deprecated) - `POST /v1/trackers/bulk/{groupId}/config` (deprecated) - `PUT /v1/trackers/{serialNumber}/config` - `GET /v1/trackers/{serialNumber}/config` - **Asset Types** - `GET /v1/assettypes/{id}` - `PUT /v1/assettypes/{id}` - `PATCH /v1/assettypes/{id}` - `GET /v1/assettypes` - `POST /v1/assettypes` - **New Endpoints** - `GET /v1/trackers/{serialNumber}/activityLog` ## Version: GA 2.0.0 Source: [https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html](https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html) This document outlines the changes and enhancements made in the GA 2.0.0 release of the Aware Cloud Platform. This upgrade aims to improve performance and user experience. **Release Date:** April 9, 2025 ### New features - **Aware Open** The Aware platform continues to offer a range of features designed to enhance observability, based on secure provisioning, and onboarding processes. These features ensure comprehensive data collection, robust security, and seamless integration across various chipsets and operating systems. In this release, the following chipsets–QCM6690 and QCM6490–are now enabled with **Aware Open Basic** functionality. Note that this is only applicable for Android. Linux SPs aren't supported yet on QCM6690/6490. **What's Aware Open Basic?** Aware Open Basic is a device observability service that provides customers with a device's coarse location and health metrics such as battery level, resource usage, software version, and much more. These metrics are available for customers to consume over REST APIs and also can be visualized using the Aware Service dashboard. - **Introduction of the Aware Thin Tracker with global connectivity** The **QTS112-GL** version supports global RF bands. This new variant includes an ambient light sensor with the same triggering mechanisms as the QTS110, offering enhanced functionality and global compatibility. - **Subtenancy feature** The Aware Subtenancy feature allows Aware customers such as an Enterprise or a System Integrator (SI) to better manage their customer's (subtenants) devices, users, and device telemetry data. Using this feature on the Service Dashboard allows customer to create subtenants and subtenant’s users, and allows movement of devices between Aware customer accounts and subtenant accounts, providing greater flexibility and control. ### Aware API enhancements - **Cloud Integration Enhancements for Aware Open Basic** Introduced new endpoints for Aware Open Basic devices to get the observability reports for all the devices in the tenant and also for each individual device. - **New Endpoints** - `GET /v1/observe/report` - `GET /v1/observe/report/devices/{serialNumber}` ## Version: GA 1.3.1 Source: [https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html](https://docs.qualcomm.com/doc/80-70215-1/topic/release-notes.html) This document outlines the changes and enhancements made in the GA 1.3.1 release of the Aware Cloud Platform. This upgrade aims to improve performance and user experience. **Release Date:** February 27, 2025 ### New features - **Cloud Integration Enhancements for Aware-enabled modules** - **Opaque Blob Handling:** Aware Cloud now receives an opaque blob from the Aware-enabled module as part of the check-in message and forwards it in the telemetry response. This data will be visible over the webhook notification messages. - **Bulk Update Refurbished DSNs:** Introduced a new endpoint to bulk update refurbished DSNs for a list of ASNs. - **Bulk Update Device Configurations:**Added a new endpoint to bulk update device configurations. The device configuration object includes the following fields: - Reporting frequency - Sampling frequency - Sensor Alerts thresholds for Sensitech custom devices, which may vary based on customer requirements: Temperature, Light sensor, and Event Detections (MCD, FMD) - **Bulk Update Firmware:** Introduced a new endpoint to bulk update firmware/software version, which corresponds to the version of the Aware Edge SDK. This is the SDK version if upgraded to the module. Comprehensive documentation on using the Aware Edge SDK QCX217 modules is available. - **Journey-based Subscription Service** As part of the new subscription and billing effort, a new journey feature is introduced to enable Aware customers to start and end devices on a journey. This feature is essential for customers who prefer a journey fee business model. - **Journey Concept:** The concept of a *journey* is used to signal Aware that a device is in use and therefore billable. It has no relation to shipments in Aware. - **Journey Start and End:** Customers can use the journey Aware APIs to start and end a journey for a device, indicating its usage period. - **Customer Contracts:** Depending on the customer contract, a journey starts and ends based on predefined conditions. ### Aware API enhancements - **Cloud Integration Enhancements for Aware-enabled modules** Opaque Blob Handling refers to the process where the Aware Cloud receives a chunk of data (opaque blob) from the Aware-enabled module without interpreting or modifying its contents. The cloud stores this data and includes it in the telemetry response, making it available in webhook notifications. This allows customers to send custom data through the Aware Cloud without requiring the cloud to understand the specifics of the data. - **Notification Service:** - `/v1/webhooks/notifications/{webhookId}/messages` - `/v1/webhooks/notifications/devices/{serialNumber}/messages` - **Tracker Service:** - `/v1/trackers/{serialNumber}/audit` Introduced new endpoints for bulk updating refurbished DSNs, device configurations (including reporting frequency, sampling frequency, and sensor alerts), and firmware/software versions for the Aware Edge SDK. - **New Endpoints** - `POST /v1/devices/bulk/configuration/update` - `POST /v1/devices/bulk/refurbish` - `POST /v1/devices/bulk/softwareversion/update` - **Journey-based Subscription Service** Introduced a Journey-based Subscription Service to enable customers to start and end devices on a journey, supporting a journey fee business model. - **New Endpoints** - `POST /v1/journey/start` - `POST /v1/journey/end` Last Published: Jun 05, 2026 [Previous Topic Subtenancy Feature](https://docs.qualcomm.com/bundle/publicresource/80-70215-1/topics/subtenancy-feature.md) [Next Topic DEMO Environment Overview](https://docs.qualcomm.com/bundle/publicresource/80-70215-1/topics/demo-environment-overview.md)