Heart rate API: Differentiate between "real, non-empty" data and default response

[sherlynntan]

Dear Fitbit, 

Pertaining to Get Heart Rate Intraday Time Series:
GET /1/user/-/activities/heart/date/{date}/1d/{detail-level}.json

I understand that the endpoint returns a JSON body of the heartRateZones definitions, even though the user did not wear the watch and there is no valid heart rate data. 

Is there a way to properly differentiate real data (user with heartrate values, wearing the device)? Can I safely use the fields in "activities-heart" like: 

"caloriesOut", "minutes"

as an indicator that there is real heartrate data? 

Would love to hear back,
Thanks in advance!

[benjosantony]

I am also currently using the caloriesOut in the api to differentiate empty heart rate (User did not wear the device) vs User has to not synced the  device to fitbit.

I keep track of a lasySyncDate field in my database to determine from which point I should start querying fitbit web api for data when user requests (Or scheduled trigger) to synchronize (Pull) data from fitbit.

I only  update the lasySyncDate if the data returned for a particular date is with caloriesOut as non empty value (If undefined we see it as fitbit does not have data for that user)

Originally was thinking of using the lastSyncDate from the devices as a means for this, but as the user could haver multiple devices of which some the user is actively using some not (Or user might be using both the devices), it is hard to choose which lastSyncDate should be used here.

Is caloriesOut and indicator that fitbit has users data on that date and the intra day heart rate response is not empty because user has not synced ? 

Please advise.

[Gordon-C]

Hi @sherlynntan 

The heart rate zone information displayed in the response when the user is not wearing a HR device is just describing the range for each heart rate zone.   If heart rate data was collected, then you would see additional information stating when the user was in each zone.

Fitbit does not support collecting heart rate data from 3rd party devices or manually entered data.  The heart rate data seen through the JSON response is the real data collected by the Fitbit devices.  Looking at the caloriesOut value is not necessary nor a good indicator for determining the availability of heart rate data.  

[Gordon-C]

Hi @benjosantony 

The best endpoint to determine if a user has sync'd their Fitbit device is using the Get Devices endpoint.  The response will tell you the last sync date.  Here's an example

{
"battery": "High",
"deviceVersion": "Charge HR",
"id": "27072629",
"lastSyncTime": "2015-07-27T17:01:39.313",
"type": "TRACKER"
}

caloriesOut might not be the best indicator determining whether or not the user has heart rate data, I've seen situations where we provide caloriesOut data when a user doesn't have any step data.   If there is no heart rate data, the "minutes" element name will not be exposed within the JSON response.   

[sherlynntan]

Hi @Gordon-C 
Thank you for the reply. 

By default, the heartRateZones include "max", "min", "name" properties even when there is no heartRate data collected. 

You mentioned that if heart rate data was collected, we'll see additional information stating when the user was in each zone. 
Yep, the additional information includes "caloriesOut" and "minutes" property. 

Was just wondering if the presence of these properties could serve as an indicator that there is heart rate data from the user. 

If the presence of "caloriesOut" element name is not a good indicator, how about the presence of "minutes" element name as an indicator for determining availability of heart rate data? You mentioned that if there is no heart rate data, the "minutes" element name will not be exposed within the JSON response. Is the presence of minutes property more reliable than caloriesOut and will they both be always present when a user has some heart rate data? 

We are currently using the presence of "caloriesOut" property to indicate that the user has heart rate data for the associated date. 

Otherwise, is there any other ways to determine the latest date for which the user has some valid heart rate data? 

Thank you for your help. 

[benjosantony]

Thanks for the reply. As I highlited earlier the reason I did not use the devices api to get the lastsync time because user could have different devices and different lastSyncTime for each.

Then it becomes a question of which one do I choose for lastSyncTime (For the purpose of seeing from which date I should query again when we call fitbit api again to capture users data into my system) 

If I choose the latest the I will possibly miss collecting data from the other trackers which have a earlier last sync date.  Because user might decide to sync the other devices later (Fiitbit Web api has a  unified api for all the devices data ) 

If I choose the earliest lastSyncTime , I will not miss data, but if the earliest is a device that the user has not used for let's say 6 months of a year, then I will have to keep fetching for the data again and again even though technically user is using another device  and I will reach the 150 request limit.

Any thought advise on this?