Wearable devices generate a huge amount of health data — the information is there, but turning it into something meaningful is a challenge.

Companies building health experiences run into the same problem: collecting data is just the beginning. The real work starts when you need to normalize information across devices, combine different metrics, calculate trends, and generate insights users can actually understand and act on.

That's why ROOK built the .

The User Health Profile is a new ROOK feature that transforms wearable data into a structured health profile.

Instead of working with dozens of disconnected metrics, developers get a single profile organized into five key areas:

Each profile includes normalized metrics, health scores, historical trends, and personalized insights generated from the user's recent wearable data. The system analyzes the last seven days of health information before generating the profile, giving applications a broader view than individual daily measurements can offer.

Collecting health data is relatively straightforward — creating meaningful context is much harder.

The User Health Profile combines multiple processing stages to turn raw wearable data into information applications can use right away:

This lets teams focus on building user experiences instead of designing scoring models, trend calculations, and health interpretation engines from scratch.

The User Health Profile integrates directly into your existing ROOK integration.

Customers request a profile through the API, and ROOK handles everything internally — from data validation and aggregation to scoring, storage, and webhook delivery — improving efficiency and response times.

The integration works in two steps:

The endpoint:

Send only the user identifier:

Example:

ROOK gets the from authentication and internally generates a and the request date. The API responds with and returns the request identifier:

ROOK analyzes the user's available data, primarily from the last seven days, and builds five sub-profiles:

Each sub-profile can include:

The result also includes an overall user score.

A missing metric is not interpreted as a bad result.

For example:

When a metric is missing, ROOK uses the other available metrics. The lack of information is reflected in the profile's confidence or coverage.

When there isn't enough data to calculate a sub-profile, its values may come back as null:

If there isn't enough information to generate any sub-profile, ROOK doesn't generate or send the profile.

When the profile is ready, ROOK sends it to the configured webhook:

Your application must respond to the webhook with , , or . If delivery fails, ROOK schedules retries.

The API allows:

Limits apply per user and per client.

User Health Profile is a ROOK feature that transforms wearable data into a structured health profile.

The profile organizes information into five areas:

It also includes scores, trends, and personalized insights.

It lets companies use processed health information without having to build their own aggregation, scoring, trend, and insight systems.

ROOK takes care of converting data from different sources into a consistent, integration-ready structure.

ROOK gets the from authentication and internally generates a and the request date. The API responds with and returns the request identifier:

No. The flow is asynchronous.

The API receives the request, and ROOK processes the profile in the background. When the result is ready, we send it to the webhook configured by the client.

ROOK looks at the user's previously synced data, including:

The main analysis window covers the last seven days. For some recovery calculations, ROOK may look at up to 14 days of sleep data.

No. The profile is built from data that has already been synced and stored in ROOK. The user must first connect a supported data source and allow their data to sync.

Each sub-profile includes:

The exact information depends on the metrics available for each user.

Scores are classified as follows:

These values help summarize the available information, but they don't represent a medical diagnosis.

ROOK doesn't interpret missing data as a negative result. For example, having no step data isn't the same as having a low step count. When a metric isn't available, the system uses the other valid metrics and reflects the missing information in the result's coverage or confidence.

HRV is a particularly important metric for the Cardio and Recovery profiles. It accounts for 30% of the Cardio calculation, and in Recovery, HRV together with its variation from baseline accounts for 60% of the score.

If a user's data source doesn't provide HRV, ROOK doesn't interpret the absence as a negative value or assign a score of zero. Instead, it calculates the sub-profile using the available metrics and adjusts the weighting between them. This reduced data availability is reflected in the result's coverage or confidence.

As a result, without HRV, Cardio can be calculated using roughly 70% of the originally weighted metrics, and Recovery around 40%. If other required metrics are also missing, the sub-profile's score, level, or trend may come back as null.

For this reason, Cardio and Recovery offer more complete coverage mainly for users with sources that report HRV, such as Oura, Whoop, Garmin, and Polar. For sources that don't provide HRV, such as Fitbit under current coverage, these sub-profiles may show lower confidence or may not have enough data to be calculated.

When there aren't enough metrics to calculate a sub-profile, its fields may come back as null:

That sub-profile should not be interpreted as a score of zero.

ROOK doesn't generate or send an empty profile. In that case, processing ends with an internal insufficient-data result, and no webhook is sent.

The overall score combines the five sub-profiles with the following weights:

Sub-profiles without usable data should not be treated as negative values.

ROOK compares the current score with the last available previous profile for the same user. The trend can be:

We use a stability band of approximately ±5%. The trend will be null when there's no previous profile or when one of the required scores isn't available.

Insights are observations generated from predefined rules. They can point to:

Each insight includes a confidence value tied to the coverage of the data used to generate it. It does not represent diagnostic certainty.

There's no defined maximum limit.

ROOK delivers the insights that meet the rules after removing duplicates and resolving conflicting messages.

ROOK sends the profile via a POST request to the webhook configured by the client.

Simplified example:

The client's endpoint must respond with one of these codes:

Any other response code — including other 2xx codes such as 204 — or a timeout is treated as a failed delivery. After a successful delivery, ROOK marks the profile as synced.

ROOK keeps the profile pending and attempts to deliver it again, up to 3 additional attempts after the initial failure, following this sequence:

If all four delivery attempts fail (the initial one plus the three retries), ROOK flags the document for deletion after 10 days. The total window is approximately 50 hours.

In webhooks compatible with version two, ROOK includes the header:

The client must validate this signature before processing the content.

identifies the profile's version. The first generation uses version one. When ROOK recalculates the profile, it increments this value. Clients can use it to avoid duplicates or ignore older versions.

Not necessarily. ROOK uses two filters to detect whether the data or metrics changed. When there are no changes, it can reuse the existing profile and resend it to the webhook without running the full processing pipeline.

No. The profile is generated on demand. If new data arrives after the calculation, the client must request a new generation.

Yes. Limits apply per client and per user:

When the limit is exceeded, the API responds with and includes the following headers so the client can retry correctly:

The API responds with:

This means the User Health Profile entitlement isn't enabled for the client.

No. User Health Profile organizes, summarizes, and interprets available data using rules and scoring models. Results should be used as contextual information, not as a medical diagnosis, treatment, or recommendation.

Key Selector is ROOK’s new feature that allows clients to customize the JSON structures they receive. This customization tool solves the challenge of processing unnecessary data volumes by enabling each client to define exactly which variables are relevant to their business model.

ROOK clients previously received complete data structures that included variables not used in their workflows. This resulted in inefficient data processing, higher storage demands, and increased difficulty in filtering critical information within events and summaries across the three health pillars: Body, Physical, and Sleep.

Key Selector introduces a configuration interface within the ROOK Portal, giving clients full control over their data structure.

The feature is immediately available as a customization tool within the ROOK Portal. By default, all clients will continue receiving the full data structure to ensure compatibility with existing integrations, with the option to enable customization based on their technical needs.

It is a customization tool that allows users to tailor the JSON data structures received through ROOKConnect by enabling or disabling specific variables across each health pillar and data structures such as events and summaries.

It eliminates unnecessary processing of irrelevant data and improves efficiency when handling large volumes of downstream information.

The feature is available as a customization tool within the ROOK Portal at no additional cost.

If all keys within an event are deselected, ROOK will stop sending that event entirely. This change will be reflected in your webhook configuration to avoid unnecessary traffic.

Yes. Previously disabled variables can be re-enabled without any issues.

Additionally, the ROOK Portal includes a “Reset” button in each section to restore the default configuration, which includes all keys and data groups.

To prevent data loss, any new key added to the platform will be enabled by default in your data structure.

No. The system is fully compatible with existing clients, and by default, complete data is delivered until the user decides to manually exclude elements.

Before saving any changes, the portal provides a preview of the configured JSON and allows it to be downloaded for compatibility testing in your development environment. Changes will also be reflected in the JSON Simulator tool.

New Long Term Support (LTS) version of ROOK SDKs,version 4.0.0. This version is designed to maximize the reliability, scalability, and maturity of Health Kit integrations such as Apple Health, Health Connect, and Samsung Health. This update transforms the SDK integration with your app, offering a more stable and predictable environment for developers and customers.

The version 4.0.0 It ensures that every integration with health data sources , more robust, and more predictable for all supported ecosystems:

This release outlines our strategic migration regarding the authentication schema between our backend services and SDKs. We are evolving our current model toward a stateless security architecture, specifically designed to enhance operational efficiency and streamline secret rotation.

Under this new framework, security and verification will be bolstered through mandatory signing of requests. Development teams will now be required to provide their Bundle ID/Package Name along with a secret word. These credentials must be configured directly within the ROOK Portal to ensure seamless and secure communication between services.

This transition represents a significant step forward in our commitment to providing a robust, scalable, and highly secure environment for our global partners.

Configure your secret word, meaning that this word will sign the requests between ROOK and SDK , you will need the Bundle ID (iOS) and Package Name (Android). If you don't have one of these, you will need to provide your internet domain.

Learn more about how to get this in this article

The update addresses the need to improve the synchronization and data retrieval experience of Apple Health Health Connect, and Samsung Health.

To transform the operation of the SDKs into a transparent flow, we have integrated Notification Webhook. This will allow us to notify clients of the following events:

From the version 4.0.0, Health records will include a flag to identify historical data.

This version introduces significant architectural improvements to the ROOK SDK. Please note that this is a mandatory update containing major changes that will require modifications to your current integration. The SDK version change must be made by September 30, 2026.

This is a Long Term Support (LTS) release designed to maximize the reliability, scalability, and maturity of integrations with Health Kits. This update provides a more stable and predictable environment for developers.

Version 4.0.0 is compatible with the following environments:

This version introduces significant architectural improvements. As it is a mandatory update, it contains important changes that require modifications to each client's current integration. The SDK version change must be made by September 30, 2026.

The update improves the Apple Health and Health Connect data synchronization and retrieval experience, as well as expanding direct compatibility with Samsung Health.

Starting with this version, logs include a flag to identify pre-existing data. Summaries and events prior to the SDK installation date will have the value "true" in the pre-existing data field. This allows you to differentiate historical information from new data generated after integration.

The system will report the following events:

In response to the growing demand for nutrition data, we launched theNutrition EventsIn this way, the extraction, transformation, and delivery of nutritional events from multiple connected health data sources can be achieved.

This improvement allows us to process nutrition information from devices like Fitbit (API) and platforms like Apple Health, Health Connect, and Samsung Health (SDKs). Thanks to this advancement, our customers will be able to access standardized nutritional data, processed and delivered according to availability or time intervals, depending on the source.

With , the data structure is standardized through the new object which encapsulates key information such as:

This standardization allows our partners to receive high-value information, ready for analysis or direct integration into their products.

By offering precise, hourly, ready-to-use nutrition events, this launch significantly expands our customers' analytical capabilities.

Nutrition Events operates in two modes:

The data is structured in a JSON object of typenutrition_eventwhich includes indicators such as calories, protein, fat, carbohydrates and more, plus metadata such as source, timestamp and physical activity.

Each may include the following indicators:

Events are delivered via webhook to client systems. In the case of Apple Health, events are grouped and delivered hourly with their corresponding deltas, preventing accumulation. Zero values ​​are explicitly included; no values ​​are stored.null.

No. It's a new data structure. Nutrition Events expands the scope of our platform to include food intake data.

Nutrition Events is available to all customers with active integrations with supported sources (Fitbit, Apple Health, Health Connect, Samsung Health). No additional integration is required, but webhook endpoint configuration is necessary.

This new functionality allows API-based customers to access regular updates of their users' body and physical summaries without waiting until the end of the day.

Previously, the processing of data for daily summaries relied on a final daily synchronization, resulting in periods without information during the day. This limitation prevented clients from providing immediate feedback or behavioral adjustments based on the user's current progress.

With Partial Summaries, this behavior is being addressed by delivering summary updates at four-hour intervals for the pillar of Physical. This solution ensures that information flows continuously through the APIs, automatically consolidating with the final summary, as has been the practice, at the end of the day.

The projectIt has been designed to streamline data visibility while minimizing the consumption of unnecessary resources:

To facilitate a seamless implementation, partial summaries maintain full consistency with the ROOK structure. This ensures that teams can integrate this functionality into their existing pipelines without modifying their current analysis processes.

The availability of the information is still linked to how often the user syncs their wearable with the original source, but now the ROOK team ensures that, once synced, the data is continuously available.

Likewise, this feature is only available for summaries extracted via the ROOK API from Fitbit, Oura, Polar, Whoop, and Withings.

It is a ROOK feature that allows customers to access updates to the pillar of Physical in four-hour intervals. Instead of waiting for a single summary at the end of the day, we deliver data periodically to improve visibility of user progress.

Previously, there were periods of information "blindness" because the system relied on end-of-day synchronization. This latency prevented applications from providing immediate feedback or behavioral adjustments based on recent user activity.

No. These summaries are consolidated and synchronized with the Summary final at the end of the day. The goal is to provide ongoing understanding without losing the integrity of the final consolidated data.

We perform automated polling of source endpoints every four hours. However, if a webhook delivers information before this period, the system logs the data and skips the redundant poll to optimize traffic.

The system prioritizes querying dynamic metrics such as steps, activity, and nutrition.

It is not necessary. Partial summaries are consistent with the structure of the ROOK Version 2. This ensures that our customers' existing integration pipelines are compatible without requiring modifications.

The availability of this information depends on how frequently the user syncs their wearable with its original app (Fitbit, Oura, Polar, Whoop, and Withings). If there is no syncing at the source, we will not receive updated data to process.

Since ROOKScore is linked to summary generation, a partial ROOKScore will also be generated whenever a partial summary is generated. Therefore, the health score of partially linked users can also be monitored throughout the day.

To implement partial summaries, no additional integration changes are required. If daily summary reception is already integrated, partial summaries will be received through the same channel. Additionally, two variables must be considered to ensure the summaries and partial exams are handled in an organized manner:

For more information on how to use “document_version” and “datetime”, read this article.

In response to the growing demand for nutrition data, we launched theNutrition EventsIn this way, the extraction, transformation, and delivery of nutritional events from multiple connected health data sources can be achieved.

This improvement allows us to process nutrition information from devices like Fitbit (API) and platforms like Apple Health, Health Connect, and Samsung Health (SDKs). Thanks to this advancement, our customers will be able to access standardized nutritional data, processed and delivered according to availability or time intervals, depending on the source.

With Nutrition EventsThe data structure is standardized through the new object which encapsulates key information such as:

This standardization allows our partners to receive high-value information, ready for analysis or direct integration into their products.

By offering precise, hourly, ready-to-use nutrition events, this launch significantly expands our customers' analytical capabilities.

Nutrition Events operates in two modes:

The data is structured in a JSON object of typenutrition_eventwhich includes indicators such as calories, protein, fat, carbohydrates and more, plus metadata such as source, timestamp and physical activity.

Each It may include the following indicators:

Events are delivered via webhook to client systems. In the case of Apple Health, events are grouped and delivered hourly with their corresponding deltas, preventing accumulation. Zero values are explicitly included; no values are stored .

No. It's a new data structure. Nutrition Events expands the scope of our platform to include food intake data.

Nutrition Events is available to all customers with active integrations with supported sources (Fitbit, Apple Health, Health Connect, Samsung Health). No additional integration is required, but webhook endpoint configuration is necessary.

Our ROOKScore is a health score based on 3 pillars of health: Physical Health, Sleep Health and Body Health is fed by several sub-pillars. However, these metrics were previously limited to the total result obtained at the end of the day through the pillar summaries. Therefore, with this improvement, it will be possible to receive the original data from the data sources that make up the ROOKScore throughout the day.

This functionality is designed to offer customers and users greater flexibility in managing biometric data. The new field allows customers to access metrics from manufacturers such as Oura, Garmin, Polar, Whoop, and Withings directly within ROOKScore's JSON.

Previously, customers had to choose between using ROOK's standardized scores or performing additional queries to retrieve the original data from the data source. This update resolves data fragmentation by consolidating both streams into a single data structure.

The field is integrated as an array of objects within the ROOK Score JSON. Each object includes the tag to identify the source of the information.

To ensure a successful transition to production, our team recommends following this verification workflow:

It's a new component within the ROOK Score JSON that allows you to integrate ROOKScore scores and native metrics from various data sources. This field gives our customers the flexibility to access original data without it interfering with ROOK's standardized calculations.

Currently, we allow access to data from sources such as Oura, Garmin, Polar, Whoop, and Withings. This includes specific metrics such as Oura's Readiness Score, Garmin's Body Battery, and Whoop's Strain.

It has no effect whatsoever. The ROOKScore scoring model is maintained independently within its own system.

We standardize labels in specific cases to avoid naming conflicts. For example, in the case of Oura, the generic value "" is mapped as or depending on the context of the data.

For data sources that provide granular metrics rather than a single value, such as Garmin's Body Battery, the array captures the evolution of the data throughout the day. This allows the customer to receive the detailed information as delivered by the original provider.

No, this process does not accumulate historical records within the JSON. The system replaces previous values ​​with the most recent ones to ensure that the information provided is always up-to-date and to avoid processing unnecessary data.

To enable this feature, the client must verify and activate the corresponding option within the ROOK configuration portal. Once enabled, the field will automatically appear in the ROOK Score JSON object.

It is crucial to consider that each data source uses different measurement criteria. For example, while Whoop uses a scale of 0 to 21 for strain, Polar uses a range of one to six for recovery status.

We recommend that developers always validate the synchronization of information by reviewing the field and the version of the document () included in the JSON.

We are pleased to announce the implementation of a new data processing protocol designed to identify, classify, and exclude naps within sleep summaries (sleep_summary). This update ensures that key metrics, such as total sleep duration and sleep efficiency, exclusively reflect the user's primary rest period.

In the ecosystem of wearables and portable devices, naps often skew health metrics by overlapping with nighttime sleep. To address this, we've developed a four-stage system that standardizes data from multiple sources.

To properly manage naps, we first need to define what a nap is. We will base this on how Oura classifies naps and primary sleep:

We use two processes to identify a nap, the first is by label and the second by definition.

Once sleep sessions are identified as "Siesta", they are discarded to ensure accuracy in the data analysis.

This improvement allows access to cleaner, more processed data, eliminating data noise caused by short sleep periods. By centralizing this logic in our data pipeline, we reduce the analytical workload for our clients, allowing them to focus on generating valuable insights for their end users.

Availability and validation

This functionality is directly integrated into the data delivery flow via SDK and API. Technical teams are advised to validate the information using the sleep_start_datetime_string and sleep_duration_seconds_int fields to confirm the correct classification of events.

A nap is defined as any block of sleep other than the main period of rest. To be classified as such, the session must occur outside the user's usual nighttime sleep schedule and have a minimum duration maximum of 3 hours.

Main sleep is considered to be the longest and most continuous block of sleep that usually occurs during the night.

Naps often mix their metrics with those of nighttime sleep, skewing critical data such as total sleep duration and efficiency. The goal of this process is to refine the analysis so that the metrics exclusively reflect the user's primary rest.

Our team uses two identification methods:

Following the filtering logic, if there is no previous main sleep session, the system does not discard that short block, thus avoiding misinterpretations or loss of essential sleep data.

This update is available directly in the data pipeline and is delivered through our SDKs and APIs.

Through the s for guide , the aim is to standardize how technical teams manage document versions within integrations with the ROOK SDK and APIs.

This guide helps ensure reliable communication between client systems and ROOK integration, reducing synchronization errors, incompatibilities, and the use of outdated data during integration processes.

The initiative aims to prevent common errors stemming from improper version control, such as synchronization failures, incompatibilities between environments, and the transmission of outdated data. With proper implementation of , developers can maintain more stable integrations, reduce production issues, and optimize the traceability of collected data.

The acts as a key identifier within ROOK's data structures. Each submitted data structure includes this version, which allows for validation of the delivered JSON version by referencing an update to a previously extracted and delivered data structure.

To avoid these scenarios, ROOK recommends that teams proactively validate and update health data with each new delivery of data structures according to their version.

The following recommendations should be followed when integrating ROOK and using datasets:

These recommendations aim to strengthen the reliability of the integration ecosystem and significantly reduce the risk of operational errors.

It is recommended to record the following in the internal logs:

This facilitates monitoring, debugging, and historical control of changes between versions, allowing for a faster response to incidents or inconsistencies.

To ensure a stable and consistent implementation, it's necessary to validate the integration's behavior under various scenarios. These tests help detect misalignments, update errors, and synchronization issues before going into production.

Correct use of document_version:

If you don't update it, your integration may display outdated or inconsistent data. This often leads to logic errors and problems with the end-user experience.

Ignore it completely. That indicates a misalignment or a resending of old data. The correct thing to do is:

Very simple:

No. The version is generated solely by ROOK to ensure consistency and traceability. Your integration should only receive, store, and forward it.

You will generate corrupt or inconsistent data for the end user.

Each dataset represents a complete snapshot of the user's state: they are not mixed, they are replaced.

You must validate:

For:

We are announcing the launch of the JSON Simulator, a new tool in the ROOK portal designed to simplify and accelerate the validation of integrations with our API and SDK ecosystem.

The JSON Simulator allows teams to simulate, preview, and send real JSON payloads to their configured webhook, without the need for a physical wearable or data generated by end users. The tool integrates directly with the existing configuration of the ROOK portal.

Previously, customers needed an active wearable and had to wait for data generation to validate their webhook. With the JSON Simulator, that bottleneck disappears.

The tool allows you to:

The JSON Simulator reduces integration times, removes dependency on wearables for testing, and improves understanding of how data varies across brands and structures. This enables teams to:

The JSON Simulator is available in the ROOK portal under the Tools module. Customers must have a configured webhook to use it; otherwise, they will be redirected to the configuration area.

It is a tool in the ROOK portal that allows you to generate, preview, and send real JSON payloads to the customer’s Data Webhook, without physical wearables or real user data.

It speeds up and simplifies integration validation with ROOK’s APIs and SDKs. It enables full-flow testing without waiting for real data or relying on devices.

Previously, customers needed an active wearable to validate webhook reception, which caused delays.

With the JSON Simulator, tests are immediate and fully controlled.

You can simulate any JSON available in ROOK’s Version 2 data structure by selecting:

They are real JSONs based on ROOK’s official structure, but they contain a generic user_id that does not affect your KPIs or real data.

Yes. The tool allows you to:

The simulator automatically checks its status.

If it’s inactive, you won’t be able to generate or send JSON. The portal will guide you to activate it.

The simulator respects your active settings, such as granularity and other applicable parameters.

You can generate fully populated JSON payloads without nulls—ideal for testing pipelines, dashboards, or transformations.

Generation and delivery take less than 3 seconds per request.

In the ROOK portal under Tools → JSON Simulator.

Any customer with a Webhook already configured in the portal.

If you don’t have one, the system will automatically redirect you to configure it.