# Qualcomm sensing hub APIs

The Qualcomm sensing hub (QSH) interfaces are available for hardware-based,
software-based, pre-existing, or any other QSH-compliant sensors. The QSH framework runs on low-power processors and exposes the APIs at
application processor. These APIs include the following:

- QSH client APIs and various feature APIs for application development.
- Sensor APIs to create new sensors on a low-power processor.

## Application processor APIs

QSH offers various feature APIs at the application processor, to meet specific needs of different sensor-specific use cases.

### QSH client APIs

The QSH client APIs provide an interface that enables client
code to access the QSH functionality and develop end-to-end
sensor applications. The QSH supports the following APIs:

`getSession()`

This API creates an instance of `ISession` and returns a pointer to
it.

**Syntax**

ISession* getSession();
    Copy to clipboard

**Parameters**

None.

**Response**

| **Return** | **Description** |
| --- | --- |
| `ISession*` | `ISession`: Upon success<br><br><br>`nullptr`: Upon failure |

`Open()`

This API initiates the client session created using `getSession()` API. The `Open()` API sets up and establishes communication between the client and the QSH
framework. The client must call this function only once per session.

**Syntax**

int open();
    Copy to clipboard

**Parameters**

None.

**Response**

| **Return** | **Description** |
| --- | --- |
| `int` | `0`: Successfully opened session<br><br><br>`-1`: Upon failure |

`setCallBacks()`

For a specified SUID, this API allows the user to set callbacks for
responses, errors, and events received over the session opened using
`Open()` API. This API registers the SUID with the callback functions
passed as parameters to this API.

To unset the callbacks for already registered SUID, you can pass
`nullptr` for all the three callback functions: `respCallBack`,
`errorCallBack`, and `eventCallBack`. Passing `nullptr` for all callback functions results in
an error for an unregistered SUID.

**Syntax**

virtual int setCallBacks(suid suid, respCallBack respCB, errorCallBack errorCB, eventCallBack eventCB) = 0;
    Copy to clipboard

**Parameters**

| **Parameter** | **Name** | **Description** |
| --- | --- | --- |
| `input` | `suid` | Unique SUID of the sensor for which the callbacks are being set. |
| `input` | `respCB` | Response callback function. |
| `input` | `errorCB` | Error callback function. |
| `input` | `eventCB` | Event callback function. |

Note

If any callback function isn’t defined or required, then the client can pass `nullptr`.

**Response**

| **Return** | **Description** |
| --- | --- |
| `int` | `0`: Upon success<br><br><br>`-1`: Upon failure, if all the callback functions are `nullptr`, for an unregistered SUID. |

`sendRequest()`

This API asynchronously sends a protocol buffer (proto) encoded message
to the QSH framework. The proto-encoded message has instructions or
configuration settings for the sensor identified by the SUID.

For a specified SUID, if you set the callback pointers using `setCallBacks()` API, then the response, event, or a combination of responses and events are received from the QSH framework.

**Syntax**

virtual int sendRequest(suid suid, string message) = 0;
    Copy to clipboard

**Parameters**

| **Parameter** | **Name** | **Description** |
| --- | --- | --- |
| `input` | `suid` | A unique SUID of the sensor for request is to be sent. |
| `input` | `message` | Proto-encoded request message to be sent. |

**Response**

| **Return** | **Description** |
| --- | --- |
| `int` | `0`: Upon success<br><br><br>`-1`: Upon failure, due to one of the following:<br><ul class="simple"><br><li><p>User tries to send a request over a closed session</p></li><br><li><p>Encoded message size exceeds the permissible size</p></li><br><li><p>Sending message fails due to the channel related issue</p></li><br></ul> |

`Close()`

This API closes the sensor session and terminates the communication
between the client and the QSH framework. The client must call this
function at the end of the session to release the resources and avoid
memory leaks.

**Syntax**

void close();
    Copy to clipboard

**Parameters**

None.

**Response**

| **Return** | **Description** |
| --- | --- |
| `void` | None |

For more information and example codes, see [Develop applications using the QSH client APIs](https://docs.qualcomm.com/doc/80-70030-7/topic/develop_app.html#develop-app).

### QSH direct channel APIs

QSH direct channel APIs provides low latency sensor data channel for high rate applications. Direct channel APIs use the fastRPC interface, which bypasses the standard interprocessor communication (IPC) mechanism to achieve faster communication. For more information, see [Qualcomm sensing hub APIs](https://docs.qualcomm.com/bundle/resource/topics/80-70030-7A/qsh_api_reference.html).

## Low-power processor APIs

The low-power processor APIs provide access to the following:

- QSH framework resources, such as services and utilities.
- Core functionalities, such as the diagnostic interface and timer.

You can use the low-power processor APIs to create algorithms and sensor
drivers that comply with the QSH standards. For more information, see
[Qualcomm sensing hub APIs](https://docs.qualcomm.com/bundle/resource/topics/80-70030-7A/qsh_api_reference.html).

Last Published: Jun 15, 2026

[Previous Topic
Qualcomm sensing hub architecture](https://docs.qualcomm.com/bundle/publicresource/80-70030-7/topics/architecture.md) [Next Topic
Software for application and low-power processors](https://docs.qualcomm.com/bundle/publicresource/80-70030-7/topics/software.md)