afterDate in Get Activity Log List call

[GrahamYF]

After experimentation, I've discovered a few issues with the afterDate parameter in the Get Activity Log List call (https://dev.fitbit.com/build/reference/web-api/activity/get-activity-log-list/).

The main issue is that afterDate is used to compare against the startTime property of the activity. This parameter would be way more helpful if it was compared to the lastModified property of the activity. As advised in another forum post in this community, when my webhook is notified that a user has new activities, I call the /activities/list.json endpoint for the user, passing afterDate as the last time I called the endpoint for the user. This should return all new activities logged since the last call. But it doesn't, because the Fitbit server isn't using lastModified (i.e. when they added or updated the activity), it's using whatever date the user decided to enter as the start date (for manual activities).

This renders the "query for all new activities since you last queried for activities" approach impossible, unless we say "Activities logged manually in your Fitbit App are not supported on our platform", and we aren't prepared to do that.

A workaround for me would be to use the "date" parameter in the webhook notification call as the afterDate parameter. The issue here is: what if the user enters a really old date for a manual activity? I could set the limit parameter on the call, but if I set it too low, I may miss other workouts they added on that date, or if I set it too high, I could overload my servers with too many (mostly duplicate) activities.

Which leads me to the 2nd issue in that the afterDate value has to be adjusted to local time for the call. This is an extra step that feels unnecessary and could lead to errors. Every date ever stored should be in UTC. An example is the startTime of my activity is 3PM UTC. However, I have to set afterDate 10AM for it to return the new activity (converting to EST).

Another issue is the naming of "afterDate". It is named as if the date in this parameter will be excluded from the results. A much better name would be "fromDate".

My final issue is being unable to specify afterDate and beforeDate in the same call. This would solve a few issues in that I could set afterDate to the date in the webhook notification and beforeDate to afterDate+1. Using this approach I don't have to figure out an arbitrary limit value.

Does anyone out there have the solution to all of this?

[GordonFitbit]

Hi @GrahamYF 

Thank you for your feedback on the Get Activity Log List endpoint.   Let me look over your information and see what we can do.

Gordon

[GordonFitbit · Accepted solution]

Hi @GrahamYF 

I think there is a misunderstanding of how webhooks should be used in your application.   The webhook contains the date that the activity data was created, updated and/or deleted.   This is related to all activity data, not just recorded activities.   For example, you will receive activity notifications while a user is sleeping.  This represents changes in calories burned while a user is sedentary.  The notification is also sent for all recorded exercise (i.e. manual, auto-generated, tracker recorded and 3rd party).

The best approach would be call the Get Daily Activity Summary endpoint using the date in the notification within the endpoint.  This will return the updated daily totals for steps, calories, distance, etc. along with all of the recorded activities for that day (i.e. manual, auto-generated, tracker recorded and 3rd party).  You can reconcile your daily totals data and recorded activities.  If you need more details about the recorded activities, call the Get Activity Log List endpoint using the same date in the afterDate parameter, and set the limit to the number of activities returned by the daily summary endpoint.  This will guarantee you will always get the activities recorded on that date (even for previous dates) and you will not be guessing if the limit value is too high or too low.

Regarding your concerns about the timezone of the date, all dates are returned in the user's local time.   Date timezone conversions are only needed if your application requires a different timezone than the user's local time (i.e. UTC).  We won't be able to change the parameter name from afterDate to fromDate.  This would cause a breaking change for the other thousands of applications using our Web API.  However, I can put in an enhancement request for the name change if we release a new version of the endpoint.   

Lastly, your request to set a date range using the beforeDate and afterDate parameters does sound interesting.   I will create an enhancement for this request too.   As I stated earlier, you can call the Get Daily Activity Summary endpoint, count the number of recorded exercises and use the sum for the limit value.

Gordon

[GordonFitbit]

Actually, I misspoke on some of the date values and their timezone.   For the Get Activity Log List endpoint, the startTime is returned in the user's timezone.   The lastModified date is returned in UTC.    We can clarify this in the documentation.   It sounds like you would like consistency.   I can create an enhancement request to make the lastModified date value in local time.   Again, we would probably fix this in the next version of the endpoint since this would cause a breaking change for the thousands of applications using the Web API.

[GrahamYF]

Hi @GordonFitbit,

I missed that the daily activity summary also returns recorded activities, thank you for pointing it out. Unfortunately, the activity in the daily summary is missing some information that I need, but I can at least use the array to know if there are any recorded activities for that day, and use the array length as the limit on the activity log list call, like you suggested.

Thanks for creating an enhancement request for beforeDate and afterDate.