Users profile

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.