Data Types Reference

Streaming carries realtime, roughly per-second signals only. For longer-span data (workouts, sleep, daily totals, body, nutrition) use the Unified API instead.

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.

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.

---

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.

---

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 you can stream synthetic data without hardware, which separates "my consumer is wrong" from "this device does not broadcast that".