# 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<br>                                /v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response<br>                                includes `deviceConfiguration` and<br>                                    `pendingDeviceConfiguration`. |
| Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH<br>                                /v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for<br>                                partial updates. |
| New endpoint | – | `POST<br>                                    /v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset<br>                                type. |

Table : Bulk Configuration API migration

| Category | Current API | Proposed API | Key changes |
| --- | --- | --- | --- |
| Bulk Configuration Update | `POST<br>                                /v1/devices/bulk/configuration/update*` | `POST<br>                                /v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in<br>                                bulk. |
| Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on<br>                                    `assetTypeId`. |
| Bulk Tracker Config | `POST /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better<br>                                scalability. |

Table : Group Configuration API migration

| Category | Current API | Proposed API | Key changes |
| --- | --- | --- | --- |
| Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under<br>                                    `/devices/groups/`. |
| Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by<br>                                    `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<br>                                /v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response<br>                                includes `deviceConfiguration` and<br>                                    `pendingDeviceConfiguration`. |
| Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH<br>                                /v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for<br>                                partial updates. |
| New endpoint | – | `POST<br>                                    /v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset<br>                                type. |

Table : Bulk Configuration API migration

| Category | Current API | Proposed API | Key changes |
| --- | --- | --- | --- |
| Bulk Configuration Update | `POST<br>                                /v1/devices/bulk/configuration/update*` | `POST<br>                                /v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in<br>                                bulk. |
| Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on<br>                                    `assetTypeId`. |
| Bulk Tracker Config | `POST /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better<br>                                scalability. |

Table : Group Configuration API migration

| Category | Current API | Proposed API | Key changes |
| --- | --- | --- | --- |
| Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under<br>                                    `/devices/groups/`. |
| Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by<br>                                    `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 [<u class="ph u">here</u>](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<br>                                /v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response<br>                                includes `deviceConfiguration` and<br>                                    `pendingDeviceConfiguration`. |
| Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH<br>                                /v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for<br>                                partial updates. |
| New endpoint | – | `POST<br>                                    /v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset<br>                                type. |

Table : Bulk Configuration API migration

| Category | Current API | Proposed API | Key changes |
| --- | --- | --- | --- |
| Bulk Configuration Update | `POST<br>                                /v1/devices/bulk/configuration/update*` | `POST<br>                                /v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in<br>                                bulk. |
| Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on<br>                                    `assetTypeId`. |
| Bulk Tracker Config | `POST /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better<br>                                scalability. |

Table : Group Configuration API migration

| Category | Current API | Proposed API | Key changes |
| --- | --- | --- | --- |
| Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under<br>                                    `/devices/groups/`. |
| Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by<br>                                    `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<br>                                /v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response<br>                                includes `deviceConfiguration` and<br>                                    `pendingDeviceConfiguration`. |
| Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH<br>                                /v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for<br>                                partial updates. |
| New endpoint | – | `POST<br>                                    /v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset<br>                                type. |

Table : Bulk Configuration API migration

| Category | Current API | Proposed API | Key changes |
| --- | --- | --- | --- |
| Bulk Configuration Update | `POST<br>                                /v1/devices/bulk/configuration/update*` | `POST<br>                                /v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in<br>                                bulk. |
| Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on<br>                                    `assetTypeId`. |
| Bulk Tracker Config | `POST /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better<br>                                scalability. |

Table : Group Configuration API migration

| Category | Current API | Proposed API | Key changes |
| --- | --- | --- | --- |
| Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under<br>                                    `/devices/groups/`. |
| Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by<br>                                    `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<br>                                /v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response<br>                                includes `deviceConfiguration` and<br>                                    `pendingDeviceConfiguration`. |
| Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH<br>                                /v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for<br>                                partial updates. |
| New endpoint | – | `POST<br>                                    /v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset<br>                                type. |

Table : Bulk Configuration API migration

| Category | Current API | Proposed API | Key changes |
| --- | --- | --- | --- |
| Bulk Configuration Update | `POST<br>                                /v1/devices/bulk/configuration/update*` | `POST<br>                                /v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in<br>                                bulk. |
| Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on<br>                                    `assetTypeId`. |
| Bulk Tracker Config | `POST /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better<br>                                scalability. |

Table : Group Configuration API migration

| Category | Current API | Proposed API | Key changes |
| --- | --- | --- | --- |
| Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under<br>                                    `/devices/groups/`. |
| Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by<br>                                    `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<br>                                    /v1/trackers/{serialNumber}/config*` | `GET<br>                                    /v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response<br>                                    includes `deviceConfiguration` and<br>                                        `pendingDeviceConfiguration`. |
| Update Device Configuration | `PUT<br>                                    /v1/trackers/{serialNumber}/config*` | `PATCH<br>                                        /v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH`<br>                                    for partial updates. |
| New endpoint | – | `POST<br>                                        /v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset<br>                                    type. |

Table : Bulk Configuration API migration

| Category | Current API | Proposed API | Key changes |
| --- | --- | --- | --- |
| Bulk Configuration Update | `POST<br>                                    /v1/devices/bulk/configuration/update*` | `POST<br>                                    /v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in<br>                                    bulk. |
| Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`<br>                                    *(TO BE DEPRECATED)* | `POST<br>                                        /v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on<br>                                        `assetTypeId`. |
| Bulk Tracker Config | `POST /v1/trackers/bulk/config`<br>                                    *(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better<br>                                    scalability. |

Table : Group Configuration API migration

| Category | Current API | Proposed API | Key changes |
| --- | --- | --- | --- |
| Group Config Apply | `POST /v1/trackers/bulk/{groupId}/config`<br>                                    *(TO BE DEPRECATED)* | `POST<br>                                        /v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under<br>                                        `/devices/groups/`. |
| Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`<br>                                    *(TO BE DEPRECATED)* | `POST<br>                                        /v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by<br>                                        `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<br>                                /v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response<br>                                includes `deviceConfiguration` and<br>                                    `pendingDeviceConfiguration`. |
| Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH<br>                                /v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for<br>                                partial updates. |
| New endpoint | – | `POST<br>                                    /v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset<br>                                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<br>                                /v1/devices/bulk/configuration/update*` | `POST<br>                                /v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in<br>                                bulk. |
| Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on<br>                                    `assetTypeId`. |
| Bulk Tracker Config | `POST /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better<br>                                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`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under<br>                                    `/devices/groups/`. |
| Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by<br>                                    `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<br>                                /v1/devices/{serialNumber}/configuration` | Unified endpoint under `/devices/`, response<br>                                includes `deviceConfiguration` and<br>                                    `pendingDeviceConfiguration`. |
| Update Device Configuration | `PUT /v1/trackers/{serialNumber}/config*` | `PATCH<br>                                /v1/devices/{serialNumber}/configuration` | Switch from `PUT` to `PATCH` for<br>                                partial updates. |
| New endpoint | – | `POST<br>                                    /v1/devices/{serialNumber}/configuration/applyByAssetType` | New endpoint to enable applying configuration based on asset<br>                                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<br>                                /v1/devices/bulk/configuration/update*` | `POST<br>                                /v1/devices/bulk/configuration/apply` | Standardized endpoint for applying configurations in<br>                                bulk. |
| Bulk Config by Asset Type | `PUT /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/bulk/configuration/applyByAssetType` | Enables applying configurations based on<br>                                    `assetTypeId`. |
| Bulk Tracker Config | `POST /v1/trackers/bulk/config`<br>                                *(TO BE DEPRECATED)* | *(Use assetType-based APIs instead)* | Deprecated in favor of asset-type-specific APIs for better<br>                                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`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/apply` | Unified group-level configuration endpoint under<br>                                    `/devices/groups/`. |
| Group Config by Asset Type | `PUT /v1/trackers/bulk/{groupId}/config`<br>                                *(TO BE DEPRECATED)* | `POST<br>                                    /v1/devices/groups/{groupId}/configuration/applyByAssetType` | Supports applying configurations to a group filtered by<br>                                    `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)