Health data reaches you in three steps. A wearable syncs to its own vendor app, or a phone's health store is read by an app running a ROOK SDK. ROOK normalizes that data from every source into three pillars — Physical Health, Sleep Health and Body Health — and pushes it to the webhook you configured. Your backend stores what arrives and serves it to your own apps. Nothing moves until the end user consents to share their health data.
How does health data flow from a wearable to your system?
There are two paths into ROOK, and which one applies depends on the data source:
Wearable APIs. The device synchronizes with its own vendor app — Garmin Connect, the Oura app, and so on — and ROOK reads from the vendor's API. Data ROOK never received is usually data the user never synced.
Health SDKs. Data held in a phone's health store, such as Apple Health or Health Connect, is extracted on the device by an app running a ROOK SDK. That app is either your own or the ROOK Extraction App.
ROOK then harmonizes, standardizes, cleans and normalizes what arrives, so that a sleep record from one vendor is comparable to a sleep record from another. From there, everything travels to your backend by webhook.
What does ROOK do with the data?
ROOK organizes the normalized data into three core pillars, and delivers it as daily summaries or as specific events, formatted with standardized JSON schemas:
Pillar | Covers |
Physical Health | activity, workouts, steps and related metrics |
Sleep Health | sleep sessions and their breakdown |
Body Health | body composition and vitals |
How does ROOK deliver data to me?
All data ROOK produces is delivered by webhook. Your application never queries ROOK for a user's data — there is nothing to poll and nothing to fetch.
Webhook | Delivers | Plan |
Data Webhook | Health data across the three pillars: summaries and events. | All plans |
Your endpoint has to accept HTTP POST requests and parse the incoming JSON payload. ROOK owns the delivery: it sends each payload, retries on failure, and signs every delivery with the X-ROOK-HASH header so you can verify it came from ROOK. For how to configure the endpoint, what counts as an accepted delivery, the retry schedule and how to verify the signature, see How do I set up webhooks in the ROOK Portal?.
Why shouldn't my app query ROOK for data?
Because the ROOK API is not a backend and not a storage system. ROOK delivers each record to you once, and your system is where that record lives from then on.
When one of your users opens your app, your app should read from your database, not reach out to ROOK. Designing it the other way puts a third-party dependency in the path of every screen your users open, and it will not scale with your traffic.
What architecture does ROOK recommend on your side?
Wearable data must synchronize with the vendor's official app before ROOK can receive it.
Health store data must be extracted on the device by an app using a ROOK SDK — your own app, or the ROOK App.
ROOK stores and processes the data before sending it to you.
Your backend exposes an endpoint that accepts HTTP POST and parses JSON. This is the only way data leaves ROOK.
Store everything ROOK sends you in your own database, in whatever shape makes sense for your system.
Your frontend services — mobile apps, web applications — read from your backend, never from ROOK.
For mobile applications, you can notify users through Apple Push Notification service (APNs) or Firebase Cloud Messaging (FCM).
What should I get right when I build this?
Verify every delivery. Check the
X-ROOK-HASHheader before you trust a payload. See How do I set up webhooks in the ROOK Portal?.Validate what arrives. Check the structure and content of each payload rather than assuming it.
Keep Sandbox and Production separate. Each environment has its own configuration and its own credentials. See How do ROOK Sandbox and Production credentials work?.
Make your storage tolerate a repeat. Design your writes so that receiving the same record twice does not create two of it.