We are pleased to announce the release of ROOKScore 2.0, our enhanced health score. This new version introduces advanced metrics and improved functionality, allowing customers to gain deeper insights and foster greater innovation with users' health data.

ROOKScore 2.0 is a redesign of our health score, aimed at making it more consistent, providing a clearer overview of key user health indicators. While ROOKScore 1.0 offers a solid foundation, it lacks the depth and robustness needed to address the diverse needs of health-focused applications. This new version is built around our three health pillars: Body Health, Physical Health, and Sleep Health, offering a more personalized scoring system based on multiple factors.

As mentioned, ROOKScore 2.0 allows configuration of the health score’s structure, meaning you can adjust the weight of each health metric or pillar, or deactivate them if they should not contribute to your ROOKScore. To configure your ROOKScore 2.0, log in to your ROOK Portal and go to the ROOKScore module. Keep in mind the following:

To access ROOKScore 2.0, please contact the ROOK team.

ROOKScore 2.0 is the enhanced version of our health scoring system. This version includes advanced metrics and improved functionality, offering a deeper and more accurate assessment of user health.

ROOKScore 2.0 incorporates additional health metrics like body mass index (BMI) and heart rate variability (HRV), as well as a new three-pillar structure: Body Health, Physical Health, and Sleep Health. It also allows metric customization and provides a more dynamic evaluation based on multiple days rather than daily snapshots.

ROOKScore 2.0 includes new metrics such as BMI, steps, calories burned, activity time, and sleep duration and quality, offering a more comprehensive view of physical, body, and sleep health.

The three pillars are:

Each of these pillars contributes to the final score and can be configured based on customer needs.

Yes, ROOKScore 2.0 allows customers to adjust the weight of each metric and pillar according to their priorities. This offers the flexibility to focus on the most relevant aspects of user health.

ROOKScore 1.0 will continue to function for some time. However, we recommend migrating to ROOKScore 2.0 to take advantage of its new features. We provide documentation and support to ensure a smooth transition.

To configure ROOKScore 2.0, log in to the ROOKScore module in your ROOK portal, where you can adjust the weight of the health pillars and metrics. Assign a percentage to each pillar (Body Health, Physical Health, and Sleep Health) and metric, ensuring that the total adds up to 100%.

If you do not want a pillar or metric to participate in the score, you can deactivate it or assign it a value of 0%, which will prevent it from contributing to the ROOKScore.

To integrate ROOKScore 2.0, contact the ROOK team for access and technical support.

We are excited to introduce our new feature, "Step Events." This enhancement allows users to obtain hourly step metrics, significantly improving the experience and insights available to our customers.

Previously, the only way to access step data through ROOK was via the Physical Summary, which provides a daily summary of steps after the day ends, or through Physical Events during specific activities. However, many customers have expressed the need to obtain step information throughout the day at various times. In response, we developed "Step Events," a solution that allows frequent and manual step updates, getting as close to real-time as possible.

Step data accumulates from 00:00 to the current time of day and is transmitted via an optimized JSON to ensure quick visualization of the metrics. Here is an example of the JSON used:

“Step Events" is a new feature launched by ROOK that allows users to obtain hourly step metrics. This functionality significantly enhances the user experience and provides more detailed insights for our customers.

No, this functionality is integrated with the ROOK SDKs.

"Step Events" addresses the need for more frequent step information updates, allowing manual and frequent data updates, getting as close to real-time as possible.

The SDKs extract and update step data as frequently as possible in the background, every hour.

Available for iOS, Android, React Native, Flutter, and Capacitor SDKs.

On iOS devices, data is extracted from Apple Health; on Android devices, data is extracted from Health Connect and the Android operating system data.

Step data accumulates from 00:00 to the current time of day and is transmitted via an optimized JSON to ensure quick visualization of the metrics.

At ROOK, we continually strive to enhance our API's ability to deliver meaningful and actionable health data. In line with this commitment, we are pleased to announce the release of ROOKScore 1.5, a significant update to our readiness score.

Many users observed that the readiness score consistently displayed a rating of 100% in various scenarios. After thorough analysis, we identified that the issue lay in the intervals defined for generic users, i.e., those whose age or gender were not specified.

Initially, the readiness score intervals were as follows:

The breadth of these intervals, averaging 82 points, contrasted markedly with the narrower average range of 35 points for users with known age and gender. This disparity caused the readiness score to be disproportionately high for generic users, often resulting in a perfect score of 100%.

To address this, we conducted a review and adjustment of the intervals for generic users. This process incorporated data on average population ages from recognized sources such as the United States Census Bureau, Eurostat, and the Instituto Nacional de Estadística y Geografía (INEGI). Based on this research, we have established the following updated intervals:

These refined ranges better reflect global population trends and are expected to provide a more accurate readiness score for generic users.

With ROOKScore 1.5, we are confident that our readiness score will now offer more precise insights, allowing our users to maximize the potential of our API. We remain committed to continuous improvement and appreciate ongoing feedback to ensure our tools meet the highest standards of accuracy and utility.

ROOKScore 1.5 is an update to our ROOKScore, designed to offer a more precise measurement through the readiness score, adjusting for global demographic trends for users who do not have demographic data.

It was identified that the undefined demographic intervals for generic users were too broad, resulting in disproportionately high and irrational readiness scores. This update adjusts those intervals through demographic data standardization to improve accuracy.

The new intervals were defined using data on average population ages from recognized sources such as the United States Census Bureau, Eurostat, and INEGI. The following age ranges were established for users without demographic data:

We expect the readiness scores to be more accurate and better reflect demographic reality, providing more useful insights.

ROOK is excited to announce the official launch of our new Capacitor (Ionic) SDK, designed to streamline the integration of ROOKConnect for both Android and iOS platforms. This SDK offers a robust solution for developers using Capacitor in their projects, delivering an integration experience akin to that of our React and Flutter SDK.

Our SDK, developed in TypeScript, provides developers with the flexibility to integrate it using either TypeScript or JavaScript, catering to their specific development preferences and requirements in Capacitor. This adaptability ensures that developers can work with the tools that best fit their workflow.

With this innovative tool, we are committed to providing our clients with access to valuable and actionable health data, empowering them to innovate and deliver enriched user experiences.

For detailed instructions on integrating ROOK with the new Capacitor SDK, please refer to our documentation.

The ROOK Capacitor SDK is a cutting-edge tool designed to simplify the integration of ROOKConnect into applications developed with Capacitor, supporting both Android and iOS platforms.

The primary aim of the Capacitor SDK is to provide seamless integration capabilities for clients developing their products with Capacitor (Ionic).

The Capacitor SDK is developed in TypeScript but supports integration using both TypeScript and JavaScript.

The SDK utilizes native libraries of iOS and Android to extract data from Apple Health on iOS devices and Health Connect on Android devices. For integrating additional data sources, please refer to our API documentation.

ROOK offers a range of actions related to users, data, and clients. These actions include linking or unlinking data sources, extracting, processing, and delivering data, and utilizing the Data Webhook to notify clients when a user event or webhook is available.

Previously, ROOK lacked a way to notify clients about various user actions occurring within their integration with ROOK. Clients could only access partial information about actions executed in their integration. To address this, we have introduced the Notification Webhook, our new add-on designed to send notifications to clients about actions within their ROOK integration. This includes creating new users, connecting or disconnecting data sources, failed notifications to user data sources, and notifications of undelivered information. Our goal is to provide clients with timely updates without requiring API queries, using webhooks to deliver automatic notifications. This optimization ensures clients have up-to-date information and streamlines their workflows.

This webhook notifies you whenever a user interacts with the ROOKConnect integration, except for Events and Summaries, which are covered by our Data Webhook. The actions that trigger notifications include:

This notification alerts you when ROOK is unable to extract user event or summary data due to various factors while querying a user's data source. These factors are external to ROOK and may include:

This notification alerts you when you have not accepted a submission of events or summaries from our Data Webhook. For more details, please read the following article.

This add-on is optional. To subscribe, please contact our sales department. You will need the following information:

No, the webhook for receiving new events and summaries is called the "Data Webhook." The "Notification Webhook" only communicates user interaction actions, failed communications to user data, and the resending of rejected information.

Yes, you can use the same URL for both environments, but we do not recommend it. Using the same URL might lead to an overload of notifications and cause confusion.

No, this add-on is optional. Clients can choose to subscribe if they need to receive automatic notifications about actions within their ROOK integration.

To subscribe to the Notification Webhook, clients should contact our sales department. You need to provide two URLs to receive webhook notifications: one for the Sandbox environment and another for the Production environment.

Yes, you can unsubscribe from the Notification Webhook by contacting our sales team to initiate the unsubscription process.

The Notification Webhook provides three types of notifications:

The "Rejected Information" project focuses on improving the delivery of information to customers by implementing a system that allows storing events and summaries, which have not been received by our customers, in specific buckets so they can request and retrieve any pending documents proactively. In this way, our aim with the project is to mitigate information loss and ensure effective data delivery to customers. The project also includes implementing a retry process before storing the documents in the bucket, which consists of notifications to the customer to make them aware of pending events and webhooks awaiting acceptance.

The operation of the "Rejected Information" project can be described in the following steps:

This project ensures that events and summaries not sent to customers are securely stored in production or sandbox buckets, allowing customers to request pending information in case of initial delivery failures. Additionally, notification mechanisms are established to ensure effective data delivery to customers.

The goal of Resend Reject Information is to improve the delivery of information to customers by ensuring they receive the maximum amount of data about their users, so we aim to maintain communication despite the lack of response from the customer's side.

The objective is to establish a system where information sent to customers is stored in buckets to allow them to request and retrieve any pending documents, thus mitigating the risk of information loss.

Events and summaries not received by customers will be stored in their respective buckets within their environment. For the production bucket, events and summaries will be stored for 10 days, and for the Sandbox bucket, they will be stored for 3 days. After this period, they will be deleted from the buckets, but the customer can still request the events and summaries. This has to be requested directly to the account manager and will incur an additional cost.

Before storing documents in the specific bucket of the environment, a retry process is initiated, which involves two attempts to send the document to the customer at intervals of 2 hours and 24 hours after the first notification. If the customer does not receive the document after the retries, then it is moved to the respective bucket.

The system will use webhooks to notify customers when events and summaries are queued for delivery and are not successfully received. Customers can also request the resend of pending documents through the designated endpoint.

Separate buckets and endpoints will be established for sandbox and production environments to ensure different handling of documents for each environment.

You will need to send us a URL where you want the notifications to be sent; this process will be manual for the time being.

A changelog is a tool for timely and clear communication about new changes, in this case, regarding our SDKs. It serves as a historical record of updates, improvements, bug fixes, and new features implemented in the product.

The importance of the changelog lies in several aspects:

To manage the changes in our SDKs, we have defined update rules to maintain semantic versioning for an optimal experience.

This guide will help you quickly interpret and understand what types of changes have been made in our SDKs through the Changelog:

To view the Changelog of our SDKs, please refer to the documentation of each SDK at the following link.

HTTP response status codes indicate whether a specific HTTP request has completed successfully. The answers are grouped into five classes:

Granular data refers to specific details about health metrics, such as heart rate, blood pressure, and blood oxygen levels. This information is essential for in-depth analysis, but the data sent from granular data can be very large.

This project aims to optimize the structure of health data delivered through webhooks by removing granular data. This benefits clients who, due to their technology, cannot process large .JSON files. In this release, we will focus on the files delivered through our webhooks.

No, the changes will apply to version 2 of the data structure, only in webhooks.

Granular data refers to specific details about health metrics.

Yes, it can be configured if granular data will be received.

Yes, this feature is on request. So, if you wish to continue receiving granular data, you don't need to request anything.

No, currently we do not have available customization of the granular data structure.

No. If you make the query via API, you will receive the entire JSON in full, including the granular data.

This project will focus on providing customers with real-time logs of their queries to track their integration with ROOK. These logs include information about event queries and user summaries. Implementing these logs efficiently can facilitate issue resolution and enhance the overall quality and independence of our product.

The project will feature a new module, "Logs," in the ROOK Portal. Here, you can view your queries directly and in real-time, historically, made through the integration of our Webhooks APIs with ROOKConnect. You will be able to review the following data:

The benefits of this project include:

The main goal of this project is to provide our clients with the ability to access real-time logs that track integration with ROOK. These logs contain detailed information about event queries, as well as user summaries.

Through the new Logs module, users will be able to view key information, including the date and time of the query, the log type, the associated User ID, the query status, and the consulted data source. Additionally, they will have the ability to review specific details of each successful query delivered in the form of events and summaries, with access to the corresponding JSON files.

The efficient implementation of real-time logs will allow quick and accurate identification of any integration issues.

Clients will benefit from increased independence by easily accessing detailed information about their queries. This will provide them with the ability to autonomously resolve issues, improve the quality of their integration, and quickly find the information they need, contributing to a more efficient and autonomous experience.

The ability to query past JSON events and summaries provides clients with complete access to historical information about their users. This not only facilitates the review of previous queries but also allows for retrospective analysis, serving to improve processes and optimize future integrations.

Currently, we work with two types of logs, which vary according to the pillar being queried. These log types are events and summaries.

We work with HTTP response status codes, which are:

Yes, the queried logs can be exported in a CSV file.

Currently, you can only check the logs for events and summaries with a 200 - Successful response. If it doesn't meet any of these conditions, the logs will not have a detailed view or a JSON.