The "Resend of 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 "Resend of 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.

To use this feature, a "status" system is introduced.

In Status 1, six specific data sources are automatically linked: Garmin, Polar, Withings, Fitbit, Oura, and Whoop. Device unlinking is possible, but re-linking must be done manually.

This approach aims to address the Demo_User functionality and provide clients with an automated and efficient solution for testing with real data from real users.

When a client creates their credentials and starts the integration, they will have the option to allow our team to automatically link to their "connection page". This will allow the sending of real information from a real user, facilitating the visualization of behavior.

This feature must be activated by a status, since not all clients will want to use it. "Status 0" (default) means that we will not automatically link to the client's "connection page", and they will be responsible for linking their devices. By changing to "Status 1", automatic device linking is activated. To have this alternative, contact our team so they can enable it.

If they have status 1, the client should see in their portal (dashboard) that they have 6 links and will start to see the information that arrives from each of them.

The goal of the Duplicity Project is to facilitate an uninterrupted flow of data from users who are connected to multiple data sources. This capability empowers our clients to make informed decisions based on their users' data, assured of its superior quality. The project's architecture is built around critical elements such as data prioritization, event generation, summary creation, and the cleansing of data within these summaries. This approach ensures that our clients have access to the most relevant and accurate information, enabling them to take proactive and effective actions based on user data.

Rook's method for managing multiple data sources begins with the crucial step of data prioritization. The accompanying table illustrates our ranking of data sources across our 3 health pillars. This ranking is based on the quality and comprehensiveness of the data each source provides in relation to the specific metrics constituting each health pillar.

The table's arrangement, from top to bottom, reveals a clear preference hierarchy. Data sources directly linked to biometric devices take precedence over health kits. Additionally, the hierarchy within these data sources is evident. For instance, Garmin is the top choice for data related to Physical Health, whereas Oura is the foremost source for sleep-related data.

ROOK provides refined, processed data from our health categories in the form of events and summaries. The Data Duplicity feature in ROOK has a defined method for managing duplicate data points related to a particular event. Priority is assigned to the first recorded event. Later events from different data sources, occurring within a close time range, are disregarded. We permit a time frame of plus or minus 10 minutes to capture a maximum of two successive events within this interval. In this procedure, priority is given to data sources that are directly connected to wearable devices over health kits and SDK extractions.

The creation of summaries relies on the data available at the time of calculation. Initially, a summary is formed using the first data source received. This summary is then enhanced with extra data from other sources. Once the initial summary is dispatched, there is a 15-minute interval before an updated summary, incorporating any new data, is sent. These subsequent summaries are marked as updated versions.

When confronted with two distinct summaries originating from the same date, both are attributed to the corresponding day. Herein, the process of data cleaning is invoked: data originating from the source deemed most relevant within the specific pillar takes precedence. This primary data is then supplemented with additional information sourced from other sources, in accordance with their position in the prioritization table. This meticulous methodology is designed to furnish comprehensive information without manipulating the original data, thereby ensuring accuracy and fidelity to the primary data sources.

The fundamental aim of the Duplicity project revolves around interconnecting two or more data sources to mutually enhance their capacities. This comprehensive integration endeavors to furnish our clients and users with a more enriched and thorough oversight of the information provided.

Prioritizing data sources hinges upon specific pillars defined within the framework of ROOK. We rely on a ranking table that assesses the scientific substantiation endorsing each data source's specialization within a given pillar. For instance, Garmin holds the highest priority in physical health, while Oura assumes precedence in sleep health.

Summaries initiate with data from the primary received source and are augmented with supplementary information from other sources based on their priority levels. A 15-minute interval ensues between the receipt of the initial summary and any subsequent summaries before disseminating consolidated information to the client.

Indeed, a meticulous data cleaning strategy is implemented. When two summaries from different sources with identical dates are received, precedence is granted to information sourced from the most relevant data source concerning the specific pillar. This information is then complemented by data from other sources based on their placement in the prioritization table.

In cases where summaries from diverse sources present contradictory data but share the same date, the Duplicity project prioritizes information from the data source deemed more pertinent to the specific pillar. This data is amalgamated with additional insights from other sources based on their standing in the prioritization table, aiming to provide a comprehensive and coherent perspective without altering the original data.

Upon reception of additional summaries subsequent to the initial delivery to the client, an update notification is dispatched. The client then has the discretion to review and implement this update, facilitating the generation of an updated version of the summary. This process keeps the client informed of any supplemental information received post the initial dissemination.

A lucid protocol is established: precedence is afforded to the initial recorded event, disregarding subsequent events from other sources sharing a similar timestamp. A window of +/- 10 minutes is permitted for continuous events, allowing the recording of up to two events if they fall within this timeframe.

🔒 Enhanced Security Update: Blocking Connection Page Access

We currently have a connection page, this helps our clients a lot to validate and observe how our solution works. This connection page is located in both Sandbox and production.

Exciting news! Our clients can now bolster their security by blocking access to the connection page. This page has been an invaluable tool for clients to validate and observe our solution's functionality, present in both the Sandbox and production environments.

To prioritize everyone's safety, we've introduced a new internal feature. Clients now have the flexibility to disable the connection page specifically in the production environment. Once disabled, attempting to access the page will result in an error, rendering it non-functional.

When the page is locked, it will display as follows: [view.]

We recommend using the Connections Page for quick data flow tests. However, in the production environment, we strongly advise clients to create their own customized connections space. This not only enhances security but also allows them to personalize it with their preferred colors and designs

Should you require further assistance or have questions about this feature, please don't hesitate to reach out to our dedicated support team.

To ensure that the information received in your webhook is authentic from ROOK, we have implemented a new security measure by sending an HMAC code as a called as part of the information sent.

This new header will only be available for version 2 of our webhooks.

To use this functionality, our team will give you a secret hash key to create the HMAC. This key is unique to you and therefore you must store it correctly.

The HMAC code sent in the header is the result of the union of the following information.

It is the union , as you can see in the example below

To this we add that the that we have previously given you is used as the encryption key and finally the encryption .

That will be the value you will receive in the X header in your webhooks.

It is important to keep in mind that your secret hash key is partially formed by your secret key, which means that if you change your secret key, your secret hash key will also change.

You can validate quickly using the following online tool.

To know if the value sent by ROOK is real, you will need to repeat the above process on your system internally. An example is shown in Python to be able to validate the hash by taking a summary of the body.

Our project, focused on optimizing Webhooks, is geared towards efficiently delivering user information to our clients via these tools, ensuring swift and robust responses to their queries. Moreover, we've fine-tuned requests and queries to operate with heightened efficiency within the limitations of our data sources, ultimately aiming to elevate the overall customer experience.

Webhooks serve as a mechanism for applications to promptly dispatch real-time data or notifications to other applications upon the occurrence of specific events. For instance, in the context of ROOK, when an event is registered or a summary is generated within one of our data sources, the webhook promptly triggers an HTTP request to a client's designated URL. This transmission includes comprehensive details about the event or summary, providing the client with the option to accept or decline the information.

This seamless integration between data sources, ROOK, and our clients eliminates the need for continuous client queries on ROOKConnect or ROOKConnect's continual monitoring of linked users' data sources for updates. Webhooks play a foundational role in APIs by enabling real-time integration and swift synchronization among all involved stakeholders.

Throughout this project, our primary emphasis has been on optimizing incoming webhooks from diverse data sources. This optimization ensures that upon data acquisition, we promptly inform our clients through our established data channels.

Within the framework of this project, we've successfully optimized the following data sources:

The response time of Polar's webhooks is under 1 minute when the user synchronizes the data source (mobile application) with their device. In cases where direct synchronization doesn't occur, it can take between 10 to 60 minutes. The available pillars with this webhook are:

The response time of Fitbit's webhooks ranges from 5 to 15 seconds when the user syncs the data source (mobile application) with their device. In cases where direct synchronization doesn't occur, it may take between 7 to 15 minutes. The available pillars with this Webhook are:

The response time of Oura's webhooks ranges from 1 to 5 minutes when the user syncs the data source (mobile application) with their device. The available pillars with this Webhook are:

Garmin's webhook response time is 1 minute only when the user synchronizes the data source (mobile application) with their device. Hence, it won't synchronize until the user opens their data source (mobile application). The available pillars with this Webhook are:

Withings' webhook response time is 1 minute only when the user synchronizes the data source (mobile application) with their device. Hence, it won't synchronize until the user opens their data source (mobile application). The available pillars with this Webhook are:

ROOK's Webhooks have been enhanced to optimize the delivery of information from multiple data sources. We've focused our efforts on improving efficiency and speed in responding to queries, enabling a smoother and more effective user experience.

This enhancement not only ensures greater efficiency in data delivery but also allows for better utilization of available data sources. Clients will experience faster and more robust responses to their queries, significantly enhancing their experience.

The data sources improved in this project are:

The limitations of optimizing webhooks are as follows:

Some pillars, such as physical summaries or body health, cannot be obtained via webhooks because the data source lacks webhook implementations for them. Hence, they can be acquired through endpoints. This is due to the policies set by these data sources.

We are working on Whoop's Webhooks. Currently, Google Fit does not work with webhooks, so they will not be optimized.

Queries can still be made via endpoints; webhooks are merely a tool to automate notifications of incoming events and summaries.

No, internally, we integrate the webhooks for each data source, meaning we centralize them and notify you through our ROOK webhook using a single URL. This URL should be entered by the client in the ROOK portal, in the notifications section of the configuration module.