Get Activity Time Series by Date Range
chevron down
 

Get Activity Time Series by Date Range

Retrieves the activity data for a given resource over a period of time by specifying a date range. The response will include only the daily summary values.

Scope: activity


Request

GET /1/user/[user-id]/activities/[resource-path]/date/[start-date]/[end-date].json

URI Arguments
user-id required The encoded ID of the user. Use "-" (dash) for current logged-in user.
resource required The resource of the data to be returned. See supported values in the Resource Options section.
start-date required The start date specified in the format yyyy-MM-dd or today.
end-date required The end date specified in the format yyyy-MM-dd or today.

Maximum range: See Resource Options

Query Parameters
timezone optional Returns the response from the specified timezone.
Supported: UTC
string

Request Headers
authorization required Specify the token type and Fitbit user’s access token.
Token type: Bearer
accept optional The media type of the response content the client is expecting.
Supported: application/json
accept-language optional The measurement unit system to use for response values. See Localization.
accept-locale optional The locale to use for response values. See Localization.

Examples
GET https://api.fitbit.com/1/user/-/activities/steps/date/2019-01-01/2019-01-07.json
GET https://api.fitbit.com/1/user/GGNJL9/activities/steps/date/2019-01-01/2019-01-07.json
curl -X GET "https://api.fitbit.com/1/user/-/activities/steps/date/2019-01-01/2019-01-07.json" \
-H "accept: application/json" \
-H "authorization: Bearer <access_token>"


Response

Element Name Description
activities-<resource> : datetime The date of the recorded resource in the format yyyy-MM-dd.
activities-<resource> : value The specified resource's daily total.
{
  "activities-steps": [
    {
      "dateTime": "2018-12-26",
      "value": "2504"
    },
    {
      "dateTime": "2018-12-27",
      "value": "3723"
    },
    {
      "dateTime": "2018-12-28",
      "value": "8304"
    },
    {
      "dateTime": "2018-12-29",
      "value": "7861"
    },
    {
      "dateTime": "2018-12-30",
      "value": "837"
    },
    {
      "dateTime": "2018-12-31",
      "value": "4103"
    },
    {
      "dateTime": "2019-01-01",
      "value": "1698"
    }
  ]
}
      

Response Headers
content-type The media type of the response content being sent to the client.
Supported: application/json
fitbit-rate-limit-limit The quota number of calls.
fitbit-rate-limit-remaining The number of calls remaining before hitting the rate limit.
fitbit-rate-limit-reset The number of seconds until the rate limit resets.

Note: The rate limit headers are approximate and asynchronously updated. This means that there may be a minor delay in the decrementing of remaining requests. This could result in your application receiving an unexpected 429 response if you don't track the total number of requests you make yourself.

Response Type

HTTP Status Code HTTP response code. List of codes are found in the Troubleshooting Guide.
Status Message Description of the status code.
Response Body Contains the JSON response to the API call. When errors are returned by the API call, the errorType, fieldName and message text will provide more information to the cause of the failure.

Response Codes
200 A successful request.
400 The request had bad syntax or was inherently impossible to be satisfied.
401 The request requires user authentication.

Note: For a complete list of response codes, please refer to the Troubleshooting Guide.

Additional Information

The activity log entries for a given day are displayed in the format requested using units in the unit system corresponding to the Accept-Language header provided.

Considerations

  • User data is only available since the user's join date or the first log entry date for the requested collection.
  • The tracker/... resource represents the daily activity values logged by the tracker device only, excluding manual activity log entires.
  • The tracker/calories resource does not include the Estimated Energy Requirement for calories estimation (EER) calculations for any dates even if they are turned on for the user's profile and use BMR level instead.
  • Elevation time series (/elevation, /floors) are only available for users with compatible trackers.
  • The activities collection are maintained for backwards compatible resource URLs (e.g. (activities/log/calories)).

Resource Options

All Activity Tracker Only Activity Maximum Date Range
activityCalories tracker/activityCalories 30 days
calories tracker/calories 1095 days
caloriesBMR N/A 1095 days
distance tracker/distance 1095 days
elevation tracker/elevation 1095 days
floors tracker/floors 1095 days
minutesSedentary tracker/minutesSedentary 1095 days
minutesLightlyActive tracker/minutesLightlyActive 1095 days
minutesFairlyActive tracker/minutesFairlyActive 1095 days
minutesVeryActive tracker/minutesVeryActive 1095 days
steps tracker/steps 1095 days

Calorie Time Series Differences

  • calories - The top level time series for calories burned inclusive of BMR, tracked activity, and manually logged activities.
  • caloriesBMR - Value includes only BMR calories.
  • activityCalories - The number of calories burned during the day for periods of time when the user was active above sedentary level. This value is calculated minute by minute for minutes that fall within this criteria. This includes activity burned calories and BMR.
  • tracker/calories - Calories burned inclusive of BMR according to movement captured by a Fitbit tracker.
  • tracker/activityCalories - Calculated similarly to activityCalories, but uses only tracker data. Manually logged activities are excluded.

Distance, pace and speed

The Fitbit devices use the following formulas to calculate distance, pace and speed. Please note, stride length is approximated by the person's height and gender.

distance = steps * stride length
pace = time(sec) / distance
speed = distance / time(hour)

Daily activity summary and auto-detected exercises' (recorded using Smart Track) distance are estimated values based on steps and stride length. Devices that support on-device or connected GPS will record distance, pace and speed from the GPS data when the exercise is initiated using the on-device Exercise application. If the person begins moving before receiving a GPS signal, steps and stride length are used to calculate distance until the GPS connects. Intraday distance values, returned by the Intraday endpoints or Activity TCX endpoint, can be more accurate since they use the GPS data. To determine how the exercise was recorded, see "logType" values.

Some people have noticed that the standard formula for calculating pace and speed doesn't always provide accurate results. That's because pace and speed are calculated from the GPS data, while the total distance is an approximate value based on how the tracker calculates distance (GPS vs steps & stride length). The mobile application duplicates the tracker distance value by displaying the exercise summary view. This is done to provide a better user experience for the consumer. When the user drills down into the exercise details, like data charts or maps, they should see the more accurate data coming from the GPS or Intraday data.

Developers who need to display the most accurate distance values, we suggest using only the intraday distance data points instead of the activity summary.

See How does my Fitbit device calcuate my daily activity? for more information.

Webhook notifications

The Fitbit Web API can send notifications when a Fitbit user has new data to download. This is possible by implementing the Subscription API and subscribing to one or more data collections. See Using Subscriptions. Whenever the activity service recognizes a change to the user’s data, a notification is sent to your application’s subscriber.

The activity collection recognizes changes to a user’s recorded activities, step count, calories burned, distance traveled, etc. Keep in mind that even when a person is not in motion, their body is burning calories. It’s possible to receive activity notifications representing calorie burn even when the user is sleeping or stationary. Today, you cannot subscribe to a subset of the user’s activity data. So, it is the responsibility of your application to query the necessary activity endpoint(s) to reconcile the data in your system.