ROOK webhooks are geared towards efficiently delivering user information from the wearable data source to our clients ensuring swift and robust responses to their queries.
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.
We have optimized the following data sources:
Webhook to Polar
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:
sleep_summary
physical_event
physical_summary: This doesn't have a direct webhook but is accessed through a bucket.
Note: Integration of a webhook for Body Health hasn't been achieved because Polar doesn't have a webhook for this. Hence, it needs to be requested through endpoints.
Webhook to Fitbit
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:
Sleep_summary
Body_summary
Physical_event
Note: Integration of a webhook for Physical_summary has not been achieved because Fitbit lacks a webhook for this. Hence, it needs to be requested via endpoints.
Webhook to Oura
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:
Sleep_summary
Activity_event
Activity_summary
Daily_spo2
Webhook to Garmin
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:
Physical_summary
Sleep_summary
Activity_event
Note: Garmin does not allow obtaining information via webhook for Body Health, so this process will continue to rely on endpoints.
Webhook to Withings
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:
Weight_body_event
Temperature_event
Blood_pressure_event
Heart_rate_event
Physical_event
Sleep_summary
Note: Withings does not allow obtaining information via webhook for Physical Summary, so this process will continue to rely on endpoints.
Frequent questions
What has changed?
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.
What benefits does this optimization bring?
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.
Which webhooks from which data sources have been optimized?
The data sources improved in this project are:
Polar
Fitbit
Oura
Garmin
Withings
What limitations does optimizing the webhooks have?
The limitations of optimizing webhooks are as follows:
For certain data sources, webhooks have not been implemented for all available data pillars. Therefore, endpoints can be used for manual queries.
The response speed of webhooks depends on how frequently the user synchronizes the data source with their device.
Why are there pillars that cannot be obtained via webhooks?
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.
Will the webhooks of other data sources be optimized?
We are working on Whoop's Webhooks. Currently, Google Fit does not work with webhooks, so they will not be optimized.
If I have the pillars via webhooks, can I no longer make queries via endpoints for those same pillars?
Queries can still be made via endpoints; webhooks are merely a tool to automate notifications of incoming events and summaries.
Do I need to integrate a URL port for each data source to use their webhooks?
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.