> For the complete documentation index, see [llms.txt](https://docs.tryterra.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tryterra.co/streaming-api/data-types.md).

# Data Types Reference

{% hint style="info" %}
Streaming carries **realtime, roughly per-second signals only**. For longer-span data (workouts, sleep, daily totals, body, nutrition) use the [Unified API](/unified-api/getting-started.md) instead.
{% endhint %}

## What you can request

The RT SDKs accept the following values in the `DataTypes` enum. You pass a set of them to `startRealtime` (or to the `Terra` constructor on Wear OS), and each streamed payload is labelled with the matching name in its `t` field.

| Group              | Data types                                                                  |
| ------------------ | --------------------------------------------------------------------------- |
| **Cardiac**        | `HEART_RATE`, `HRV`, `RR_INTERVAL`, `ECG`                                   |
| **Movement**       | `STEPS`, `STEPS_CADENCE`, `DISTANCE`, `SPEED`, `FLOORS_CLIMBED`, `ACTIVITY` |
| **Cycling**        | `POWER`, `BIKE_CADENCE`                                                     |
| **Motion sensors** | `ACCELERATION`, `GYROSCOPE`                                                 |
| **Energy**         | `CALORIES`, `MET`                                                           |
| **Position**       | `LOCATION`                                                                  |

***

## What you actually receive

**Requesting a data type is not the same as receiving it.** Three things have to line up before a value reaches your backend:

1. **The wearable broadcasts it.** Receiving a realtime stream depends on the device being configured to broadcast that signal over BLE, ANT+, or a supported custom Bluetooth protocol. A device that does not broadcast a signal cannot stream it, no matter what you request.
2. **The connection type carries it.** A BLE heart-rate strap and a Wear OS watch expose very different sets of sensors.
3. **You asked for it.** Only the data types in the set you pass to `startRealtime` are streamed.

If you request a data type and see nothing on the stream, check them in that order: silence almost always means the device is not broadcasting that signal, not that the connection is broken.

{% hint style="warning" %}
Most heart-rate straps broadcast cardiac signals only. A chest strap will not give you `STEPS`, `LOCATION`, or `FLOORS_CLIMBED` however you configure the SDK. Those come from a watch or from the phone's own sensors. Design your app to degrade gracefully when a data type never arrives.
{% endhint %}

***

## Connection types

The `Connections` enum selects which transport you are scanning and streaming over.

| Connection    | What it covers                                                           |
| ------------- | ------------------------------------------------------------------------ |
| `BLE`         | Bluetooth Low Energy wearables: heart-rate straps and compatible watches |
| `ANT`         | ANT+ wearables, where the Android phone's hardware supports ANT+         |
| `WEAR_OS`     | A Wear OS watch running your companion app                               |
| `WATCH_OS`    | An Apple Watch, over WatchConnectivity, requires a companion watchOS app |
| `APPLE`       | Apple platform sources                                                   |
| `ANDROID`     | The Android phone's own sensors                                          |
| `ALL_DEVICES` | Any connected device                                                     |

Availability varies by platform: ANT+ is Android-only and depends on the handset, and `WATCH_OS` requires a companion watchOS app because React Native cannot build one directly. See the per-platform guides under [Wearable → Your app](/streaming-api/connect-wearable-to-sdk.md).

***

## Wear OS labels data types differently

On Wear OS, streams started as part of an exercise are labelled with the exercise type **and** the data type, concatenated. Streaming `HEART_RATE` and `STEPS` during a `RUNNING` exercise produces two payload streams typed `RUNNING_HEART_RATE` and `RUNNING_STEPS`, not `HEART_RATE` and `STEPS`.

Parse the `t` field accordingly if your consumer handles both Wear OS and BLE producers.

***

## Working out what a device broadcasts

Terra does not gate or filter by device. The broker passes payloads through opaquely and labels them with the `data_type` your producer supplied. What arrives is decided entirely by the wearable's own broadcast profile.

To find out what a specific device supports:

* **Check the manufacturer's specification** for the BLE services or ANT+ profiles it advertises.
* **Scan and observe.** Connect the device with the RT SDK, request a broad set of data types, and log which ones actually produce payloads. This is the most reliable answer for a given firmware version.
* **Use a test user.** From the **Streaming** page of the [Terra dashboard](https://dashboard.tryterra.co/dashboard/streaming) you can stream synthetic data without hardware, which separates "my consumer is wrong" from "this device does not broadcast that".