BLOGS 
NEWSROOM 
CASE STUDIES 
WEBINARS 
PODCASTS 
ASSET HUB 
EVENT CALENDAR 
Terra SDK is your gateway to a world of possibilities in health and wellness technology. In an era where data and technology are at the forefront of our lives, Terra SDK has become a powerful tool for developers. It simplifies health data integration, ensuring the utmost security and privacy while enabling real-time data streaming from wearable devices to applications. Join us as we explore the benefits and innovations that Terra SDK brings to the forefront of health and wellness app development.
What is Terra?
It provides APIs and a mobile SDK to connect your app to your user’s wearable. Terra provides a quick and simple way to connect your application to your users’ wearable data. Terra also works well with fitness applications.
Supported Wearables by Terra SDK: Terra supports connection to Bluetooth Low Energy and ANT+ devices.
Benefits of Using the Terra SDK
🔸 One API, Any Health Data: A one-time implementation facilitates the integration of devices and can be reused multiple times through the created API and SDK. These APIs or SDKs enable the retrieval of various types of health data. This is especially useful in wearable app development, where supporting multiple device families quickly becomes expensive to maintain.
🔸 SDK/API Created for Developers, By Developers:
- Terra API and SDKs allow users to build great products and services in a fast and easy way.
- As device integration is already done within the SDK, you need to write just a few lines of code to implement Terra.
- Products provided by them are engineered and optimized in such a way that they fulfil the needs and desires of developers.
- Faster to implement.
- Multiple integrations.
- Get started in less time with a few lines of code.
🔸 Trusted & Secure: It’s secured with end-to-end encryption, so your information (i.e. health-related data) is handled anonymously with end-to-end encryption.
🔸 Health Metrics: Terra provides health metrics, including heart rate, steps, sleep data, and more.
🔸 Everything is Given in One Kit: As everything is implemented and accessed using Terra’s API and SDK, It saves your time on implementing something that is already done.
Terra Integration
Health data for the users comes from different sources, such as Fitbit, Garmin, and Oura which are in different forms and developed using different technologies. Terra provides the resultant data in a structured manner, no matter the source.
It can be easily integrated with all the fitness and health wearable devices, sensors, and applications using a single API.
For more detailed information, you can visit the following link: Terra Integration
Real-Time Live Streaming
The Terra Streaming Protocol provides real-time streaming of wearable data. Terra provides a mobile SDK to stream health data directly to applications. It streams real-time data from the wearable to the application via BLE and ANT+ using the Terra SDK. Regardless of the sources, it streams data from the devices supporting Bluetooth Low Energy, ANT+, or from the phone itself.
Supported Devices for Real-Time Heart Rate Streaming: Heart rate monitors support devices such as Wahoo, Polar, Suunto, Garmin, and many others, or any devices that are equipped with BLE or ANT+ sensors, such as the WHOOP, Apple Watch, and many more.
Streaming Workflow
As shown in the above streaming workflow, wearable devices are nothing but BLE-enabled devices that can stream data to the app and backend. Upon establishing a one-time connection between wearable devices and the app, it will start streaming data to the app and backend. You can start or stop streaming data at any time using the functions provided by the SDK once a connection has been established. The web socket here is responsible for the synchronization of data received locally in the app to the web server.
Discover Terra Integrations for Seamless Healthcare Automation
Streaming SDK Implementation
1. SDK Installation: The library is part of mavenCentral! Follow the steps to install,
- Open your project in Android Studio.
- Navigate to your project’s build.gradle file, located in the root directory of your project.
- Inside the dependencies section of the build.gradle file, add the following line of code, which will add the TerraAndroid SDK as a dependency to your project.
2. Obtain the Dev ID and the API Key: Head to the Terra dashboard and then Go to API > Customise, and you will get your API Key, Signing Secret, and Dev ID. They are used with the API used in Terra SDK, so keep them safe!
3. Usage: The package revolves mainly around a single class i.e. TerraRT
4. Initialize an instance of the class:
Arguments:
- BuildConfig.DEVID: Its developer ID is taken from the dashboard.
- context: Context => The app context for which you call this function (usually from a class that extends from Activity types).
- Reference ID: Static value.
5. Generate Auth Token: After initializing the class, the next step is to generate the auth token API, which needs a Dev ID and X-API key. We can get it from the try terra dashboard. You can refer to this document for details on implementing the auth token API.
6. Initialising Connections: After getting the auth token in the API response, you can initialize connections by passing the auth token as a parameter shown below,
Upon executing this initConnection function, all necessary permissions will be requested.
Arguments:
- token => An authentication token that should be generated in your backend from the mobile SDK token endpoint.
- callback => A function that is called when the initialisation is completed with a boolean which indicates if it’s successful or not.
7. Scanning Device: After establishing the connection to the device, you can now scan for devices including BLE and Wear OS (Bluetooth). It will show an in-built scan screen provided by the SDK. Scanning results will be displayed on that screen.
Arguments:
- connection: Connections => This argument takes a Connections enum, indicating the connection you wish to make. This includes BLE and Wear OS (Bluetooth) (Please check out our WearOS SDK for this!), etc. See the Connections Enum reference for a full list.
- useCache parameter can be used if you wish to let the user simply connect to the previously connected device.
8. Data Streaming: You can now start streaming data after executing the startRealme function.
Arguments:
- connection: Connections => This argument takes a Connections enum, indicating the connection you wish to start realtime for
- token: String => It’s an optional field. It’s needed for streaming User Token for authentication to Websocket API. This can be generated from the data Streaming User Token endpoint.
- dataTypes: DataTypes => This argument takes a DataTypes enum indicating the datatype you wish to stream for.
If your team wants deeper implementation control instead of an abstraction layer like Terra, see our guide on building a BLE app from scratch.
Streaming Wearable Data Into RPM Workflows
Real-time streaming is what separates a fitness app integration from a clinical Remote Patient Monitoring (RPM) workflow. In RPM, the value of wearable data is not the data itself; it is the latency between a vital sign changing and a clinician seeing it.
A patient with paroxysmal atrial fibrillation does not need their heart rate logged once an hour to a CSV. They need rhythm changes surfaced on a nurse dashboard within minutes so the care team can intervene. A continuous glucose monitor (CGM) reading that arrives 30 minutes late during a hypoglycemic excursion is a charting record, not a clinical signal. Terra’s WebSocket-based streaming model is engineered for the second case, where the SDK pushes BLE and ANT+ data to your backend as it is generated, not on a polling interval.
For billing, this matters in a specific way. CPT 99454 requires 16 days of physiologic data within 30 days for the device supply leg of RPM. Streaming devices clear that threshold trivially. Where streaming actually unlocks reimbursement is on the management leg, CPT 99457 (first 20 minutes of clinician interactive time) and the new CY 2026 code 99470 (10–19 minutes of management time, finalized in CMS-1832-F). Alert-driven workflows generate the documented interactive minutes that justify those codes. Batch sync rarely does.
A few engineering decisions to make before going live in a regulated environment:
FHIR mapping at the edge. Terra returns structured payloads; map heart rate, SpO2, steps, and sleep into FHIR Observation resources before writing to your EHR connector. This keeps your data model interoperable with downstream HealthConnect CoPilot or with any FHIR-native EHR integration.
Encryption and compliance posture. Terra is HIPAA-compliant and SOC 2 Type II-certified, with data encrypted in transit (TLS 1.2+) and at rest (AES-256). That covers Terra’s leg of the data path. You are still responsible for encryption, access controls, and audit logging in your own backend, and for executing a BAA with Terra and with every cloud provider in the chain. See our data security guide for the full RPM stack checklist.
Battery and connection state. RPM patients are not developers. Build the connection status UI to surface “your device is connected and sending data” plainly, and design fallbacks for the 6–8 hours per day a wearable is typically off the wrist or charging.
Mindbowser’s ConnectHealth accelerator provides pre-built device integrations and FHIR mapping for the most common RPM device families if you want to skip the SDK by SDK build.
Conclusion
Terra SDK is a strong fit when your app needs to ingest data from many wearable brands quickly and your team would rather not maintain a separate BLE stack for every Garmin, Polar, Fitbit, and Oura release. The trade-off is the trade-off of any abstraction layer: you get speed at the cost of fine-grained control over the device protocol.
For multi-device fitness apps and broad-coverage RPM platforms, that trade-off usually wins. For single-device clinical workflows — a glucose monitor used in a regulated diabetes program, an ECG patch destined for a 510(k) SaMD pathway — direct integration with the device manufacturer’s SDK gives you the audit trail and protocol control regulators expect.
Whichever path you take, pair the SDK with a HIPAA-aligned backend, FHIR-mapped data layer, and a clear BAA chain before a single patient connects. If your team needs deeper protocol-level implementation detail before integrating Terra, review our guide to BLE fundamentals.
Terra is HIPAA compliant and SOC 2 Type II certified, with data encrypted in transit (TLS 1.2+) and at rest (AES-256). BAA terms are not published on their site — confirm specifics with Terra’s enterprise team before processing PHI. HIPAA compliance is not a property of any SDK in isolation; you remain responsible for encryption, access controls, and audit logging in your own backend, and for the BAA chain across every cloud provider in your data path.
Streaming latency depends on three legs: BLE/ANT+ device → phone (typically under 1 second on a stable connection), phone → Terra WebSocket (typically 1–3 seconds), and Terra → your backend (sub-second once subscribed). End-to-end you should plan for 2–5 seconds under good conditions. Build your alert thresholds with that in mind — sub-second guarantees are not realistic over BLE.
Yes. Terra connects to BLE devices, ANT+ devices, and a long list of cloud-API wearables (Fitbit, Garmin Connect, Oura, Whoop, Apple Health, Google Fit). The streaming SDK covered in this article is the BLE/ANT+ path. Cloud-API integrations use a separate REST flow and run server-side, not on-device.
Use Terra when your app needs to support many device brands quickly, when your roadmap prioritizes coverage over protocol depth, and when you do not need a 510(k)-grade audit trail. Build direct integrations when you are targeting a single device family for a clinical workflow, when you need protocol-level control for a regulated submission, or when your business model depends on a partnership with one device manufacturer.
Terra’s streaming relies on their WebSocket infrastructure — there is no self-hosted edition of the streaming protocol. If self-hosting is a hard requirement (FedRAMP environments, sovereign-cloud deployments, certain hospital IT policies), you will need to integrate with each device SDK directly or evaluate alternatives like a custom BLE bridge.
