How does ROOK structure wearable health data? Summary, events, JSON

ROOK structures wearable health data in three pillars (Physical, Sleep, and Body) and delivers each pillar in two formats: summaries, which consolidate a completed day or night, and events, which capture a specific moment such as a workout or weigh-in. Every JSON document shares the same core fields, including a document version, so you always keep the most recent record.

The hard part of building with wearable data is rarely getting the data; it is making it usable. Each manufacturer exposes different metrics, naming conventions, proprietary models, and data formats, which forces teams into ongoing integration, normalization, and maintenance work.

Prefer watching instead? See the full ROOK data structure walkthrough on YouTube.

ROOK organizes wearable health data into three pillars:

The pillars map to product design: activity dashboards use Physical, recovery insights use Sleep, and physiological or lifestyle measurements use Body.

Summary data consolidates a completed time period, while event data captures something specific that happens during the day. Both formats exist within every pillar.

Summary data is delivered once enough data is available to consolidate a period. For example:

Summary data is typically your “final” data because it:

Event data is triggered when something happens with a defined start and stop or a specific measurement. Examples:

Event data is ideal for:

Best practice: use events for intra-day interaction and summary data for end-of-day accuracy.

Every ROOK JSON document shares four core fields, even though the metrics vary by pillar:

• Client UUID (client_uuid): identifies your organization. It is generated in the ROOK portal when you set up your account.
• User ID (user_id): identifies the end user in your system. You define it, and ROOK uses it to associate all wearable data with that user.
• API version: indicates the API version (for example, v2). Mainly relevant for technical reference and backward compatibility.
• Document version: critical for data integrity, as explained below.

The document version tells you which record is newest, because wearable providers may send an initial dataset and later send an updated or corrected version for the same user and day.

Golden rule: if you receive multiple records for the same user ID, date, and data structure, always use the record with the highest document version.

Following the golden rule ensures:

For more on handling repeated records, see eliminating duplicates in wearable health APIs.

Structured data holds metrics ROOK standardizes across devices; non-structured data holds proprietary metrics unique to a manufacturer. Each JSON separates the two.

Structured data includes:

Structured data is ideal for cross-device comparisons, consistent product features, and avoiding device-specific logic.

Non-structured data includes proprietary metrics such as brand-specific readiness scores or device-exclusive indicators. ROOK does not discard proprietary metrics: it delivers them separately so you can use them without breaking normalization across devices.

A robust ROOK implementation consumes events during the day and replaces them with summaries at the end of the day:

• During the day: consume event data for intra-day updates, and use events to trigger alerts, notifications, or UI updates.
• At the end of the day: replace accumulated values with summary data, and always use the highest document version.

This pattern keeps your product responsive during the day, accurate at the end of it, and consistent over time. The next volume covers granular data, events, time zones, and proprietary metrics.

The ROOK video walks through the API reference and example JSON structures for Physical, Sleep, and Body data. For field-level detail, use the ROOK developer documentation.