This topic is for Fitbit announcements and updates on changes to the API. If you'd like to have more detailed discussions around these issues, please post them
We are happy to share with you a few things that have been keeping the team busy for the last couple of weeks this summer and which have now graduated to new features of the Fitbit API platform.
1) New resources and calls:
*Sleep & Water. *Thanks to all your feature requests, we rolled out a group of endpoints to read and write data for the *sleep and water logs* (as you may notice, we've recently released a new water tracker interface on the website, so water endpoints also reflect this new concept). As with activities and foods you can now fetch, log and delete water and sleep records from your applications. We'd love to hear your opinion what resources should make their way into the API next?
*Friends. *We started thinking about revealing some *social resources* to the API, which would allow you to create more engaging user experiences based on the Fitbit social graph. There are already endpoints up and running for fetching a *friend list*, a weekly or monthly *leaderboard* (similar to the one on Fitbit's dashboard), also for creating and managing friend invites, for each user. Note: we are currently working on changes to the social features on Fitbit, so the invitation endpoints are in early beta.
*Foods. *We already sent a note about this one, but once again, we introduced a feature to *create private foods* for the user via the API and all foods in other API responses are also marked with one of three access levels: "PRIVATE", "SHARED" or "PUBLIC".
*Profile. *We extended Get User Info endpoint with a new POST verb to *update user profile* fields.
*Subscription-API.* In addition to the endpoint for managing application's subscriptions, you can now fetch the* list of existing subscriptions* for the user.
2) There are some valuable additions to the API documentation and examples:
While we are working on our own custom solution, we thought it might be handy to have an *API Explorer *to play with endpoints without touching any source code. (http://wiki.fitbit.com/x/RYBQ)
We created a page in our API documentation where we will publish links to *3d party client libraries*. There are currently only two of them (thanks to our awesome community) in Ruby and PHP, but we are looking forward to include more. We encourage you to share your client implementations with the community in this group, and we will mention them in our documentation if they're well done. (http://wiki.fitbit.com/x/JYdG)
You might remember that we released sources for the Fitbit4J client library and Example Java Application under LGPL license. Now in addition to the full reference example, we have a small *standalone example servlet* on top of Fitbit4J that should help you kickstart development. (
http://wiki.fitbit.com/x/LYAN)
*Fitbit4J* was updated to reflect API developments. Latest binary version is 1.0.1.
3) There is one more thing that we want to discuss with the community before moving any further. As the Fitbit API matures, we are considering enforcing the SSL protocol for all steps of the initial OAuth handshake (i.e. the /oauth/request_token and /oauth/access_token endpoints) to conform with RFC5849 (http://tools.ietf.org/html/rfc5849). Currently, we support HTTPS, but we also allow clients to perform the OAuth handshake over HTTP. This change would potentially break any application which currently uses HTTP for authentication, at least until the application is changed to use HTTPS for authentication. The one useful thing we see about our current support is that being able to see wire-level traffic can be a very useful debugging tool while trying to get OAuth up and running for new applications.
What do you think? How many of your applications would be impacted by this change? How difficult would it be to change your applications?
And rest assured, before making this change, or any change which could break your application, we will provide ample advance notice to ensure that you have enough time to switch your application over to HTTPS, or fix whatever other issues may arise in the future.
Thanks for all your feedback, it is a vital part of the development lifecycle for the platform!
We have one question and one announcement to make:
Question is * What are your working on?* Every day, we are talking to you a lot directly and via this Google Group, although we're not always able to delve deeply into the details of your use cases of the Fitbit API Platform while trying to work out those issues. We really want to learn more about our fellow developers as we starting to think about promoting the Fitbit API's ecosystem on the Fitbit website.
Please, share with us your experiences and successes in working with the Fitbit Platform. And if you don't want to post publicly for any reason, please don't hesitate to contact Peter or myself directly.
*And to the announcement:*
We have just released significant changes to the rate limiting strategy for the Fitbit API. We hope that it will make integration with the API more transparent and more suitable for the common use cases than previous one. This change should not affect already deployed applications, which have implemented calls to the API according to best practices and our answers to your questions in this google group.
You may not be aware, but we group calls to the API into different quota buckets. The quota types are now *CLIENT* and *CLIENT+VIEWER*. Both bucket types are independent, ie., any single call will only be counted against one bucket type or the other, never both. Each bucket has the same limit of *150 hourly calls* as before. The *CLIENT* quota applies only to requests that are made on behalf of the application (without user's access_token in Authorization header and signature) and the *CLIENT+VIEWER* quotas (remember, there's one for each user) are used for calls on behalf of authorized users.
It's also worth mentioning that rate limiting only affects a subset of the API endpoints (mostly those which require *Read Access Level*). See the wiki for information about which endpoints are rate limited.
We've tried to avoid any changes that might affect production applications, so please contact us immediately if you notice any unexpected consequences from this change on your side.
As you might noticed we have a busy time here at Fitbit working on the new products and features for the last couple of months. We had a several big days including Fitbit Ultra and Food Goal launches. Now it is the time for the Fitbit API to catch up! We released several new API additions to support those Fitbit products in the ecosystem. Some of them have been around for a while, others are completely new and have been just released.
Let's jump to the list:
1) *Fitbit Ultra. Floors and elevation.* We have added the daily elevation and floors resources tracked by Fitbit Ultra to the API. They are available in the responses to Get-Activities calls as well as Get-Time-Series resources. Please, note that these resources currently available only for the users with a new version of tracker paired (though you could definitely fetch floors and elevation from your friend or any public profile, who has new Ultra).
2) *Food Goal. *The Food Goal is a new way to manage your daily calorie intake on the journey to the desired body weight. It is very dynamic and based on your daily activities, so we decided it might be helpful to reveal user's current food budget for the day in the API as well.
And several other additions and improvements (some of them not so small!):
We have added *sleep efficiency* to the sleep related calls and tracker's *last sync time *to the Get-Devices endpoint.
(these two were entirely based on the developer community feedback thanks!)
Support for fetching resources of other users from the user's social graph is back for all of the Get-Time-Series
calls, so now you should be able to produce awesome graphs to compare friend's activity trends over time.
We extended activity and food logging, so now it is possible to create and log *custom activities *as well
as food log entries without a reference to particular food in our database. This could simplify the food logging
workflow and also great for writing *meal summaries *with all nutritional details versus specific food entries to Fitbit.
Now, when a user revokes access to your subscription application, and outstanding subscriptions your application may have for that user will be removed, and you will immediately stop receiving subscription notifications for that user.
I think it would still be good practice to detect and gracefully handle 409 errors when trying to create a subscription, however, as these indicate that the user already has the subscription you are trying to create.
Peter
On Oct 14, 2011, at 5:09 AM, Pavel Risenberg wrote:
Hey Everyone!
As you might noticed we have a busy time here at Fitbit working on the new products and features for the last couple of months. We had a several big days including Fitbit Ultra and Food Goal launches. Now it is the time for the Fitbit API to catch up! We released several new API additions to support those Fitbit products in the ecosystem. Some of them have been around for a while, others are completely new and have been just released.
Let's jump to the list:
1) Fitbit Ultra. Floors and elevation. We have added the daily elevation and floors resources tracked by Fitbit Ultra to the API. They are available in the responses to Get-Activities calls as well as Get-Time-Series resources. Please, note that these resources currently available only for the users with a new version of tracker paired (though you could definitely fetch floors and elevation from your friend or any public profile, who has new Ultra).
2) Food Goal. The Food Goal is a new way to manage your daily calorie intake on the journey to the desired body weight. It is very dynamic and based on your daily activities, so we decided it might be helpful to reveal user's current food budget for the day in the API as well.
And several other additions and improvements (some of them not so small!):
We have added sleep efficiency to the sleep related calls and tracker's last sync time to the Get-Devices endpoint. (these two were entirely based on the developer community feedback thanks!)
Support for fetching resources of other users from the user's social graph is back for all of the Get-Time-Series calls, so now you should be able to produce awesome graphs to compare friend's activity trends over time.
We extended activity and food logging, so now it is possible to create and log custom activities as well as food log entries without a reference to particular food in our database. This could simplify the food logging workflow and also great for writing meal summaries with all nutritional details versus specific food entries to Fitbit.
We've just completed next round of the Fitbit API improvements that we want to highlight for you. Here is some of them.
Recently we revealed the case by case access to the intraday activity data in the API and we are looking for your suggestions for the
awesome applications you want to build on top of it. Please drop us a note at *api [at] fitbit.com* and describe how intraday data fits in
if you want to apply.
We extended the number of log trackers revealed in the API by adding the endpoints for reading and writing *blood pressure*
measurements that many of you asked for as well as extended the number of measurements in the *Get-Body* and* Log-Body* endpoints (including body fat). Also there is a new *avatar* picture link in the Get-User-Info call.
We pushed the *catalog of all available activities* to the API, so you could implement it in your applications to allow users
to choose and create the manual activity log entries or just to use as a reference of available options for your application
(http://wiki.fitbit.com/display/API/API-Browse-Activities).
New endpoint to get *lifetime activity statistics* for the user, as seen on the "My Achievements" tile on the Fitbit Dashboard, we
included both data from tracker and total statistics including manual log records (http://wiki.fitbit.com/display/API/API-Get-Activity-Stats).
Looking forward to see exciting leader boards and mashups using this data!
In addition to the dynamic Food Goal, we added the *daily activity goals (calories, steps, floors and distance)* to the
Get-Activities endpoint.
Additional historical time series resources for *sleep *(for the main sleep entry of the specific day) and *water*: minutesToFallAsleep,
minutesAfterWakeup, startTime, efficiency, water (http://wiki.fitbit.com/display/API/API-Get-Time-Series).
Also for those of you who love making things in Java, we updated the Fitbit4J library to the most recent version 1.0.20, which includes
wrappers for all of those changes.
We are already working on the new features and excited about what's coming next!
Hope you're all doing great during the holiday season! We prepared some news about the Fitbit API new features to keep you busy during the holidays :)
Let's start with some great visualizations made on top of the Fitbit data, that we hope would be inspiring for every developer/designer at heart. And we obviously looking forward for more great submissions from you to the App Gallery (http://www.fitbit.com/apps) that we have recently launched on Fitbit.
The first spatial installation was made by Brian House (
http://brianhouse.net/, http://nytlabs.com/projects/mirror.html) from NYT as a part of his research and among other information layers visualizes a heatmap of monthly activities from Fitbit data. The second one was made by Chloe Fan from Carnegie Mellon (http://fitbit-spark.appspot.com/) and generates unique daily visual landscapes from your activity records to make you move more as you are looking forward for a new awesome visual to reflect on in the evening.
And to the technical updates:
We have been working on some last tweaks to the Resource API endpoints extending them
with reading and writing (and deleting) of *glucose *and *heart rate *
records, so currently the API includes almost every resource data point that we have in Fitbit interface.
In addition to well-known activity *time series* resources, we added the* "clean" resources*
* from the tracker* data for those of you, who have been asking for a way to access data
"non-manipulated by the user" either for tracking challenges and behavioral change purposes
or just to be sure that the data feed doesn't include records occasionally put there through
the user interface. Please, test drive new */activities/log/tracker/* *resources in the time series
endpoint (http://wiki.fitbit.com/display/API/API-Get-Time-Series) and post here what you think.
Some small improvements here and there (e.g. BMI in Get-Body-Measurements endpoint).
As usual for those of you who is close to Java development, we updated the Fitbit4J library
to the most recent version 1.0.21, which includes updates for all of the changes above.
As you might notice, we all have been very busy here at Fitbit last month with a couple of new product launches which consumed most of our time, including new Aria scale device, major website updates and the launch of localized websites for UK, Spain, France and Germany. Although during that time we also released some number of the new API features and improvements that we would like to highlight:
In anticipation of the Aria launch we added couple of endpoints to support a new weight
storage architecture. Main change is that from now on we support any amount of weight
and body fat measurements during any specific day, including entries from the scale and
manually logged ones. That being said, all previous body related endpoints (i.e. Get-Time-Series,
Get-Body-Measurements, Log-Body-Measurements) are still backward compatible and
good to go, just revealing only one last entry per any specific day, which should be enough
for most applications to track user's weight through time. For those interested in a more data, here are new calls worth looking at:
As a kick-start of *localization* efforts around the API, we introduced new concept of the
"Accept-Locale" custom header for all activity related endpoints, which include
language-specific names of activities and intensities in response. We are looking forward
to extend localization support for the API in the future, but will use the same concept.
"*Accept-Locale*" header currently supports the following values as our website does:
"en_US", "en_GB", "de_DE", "fr_FR", "es_ES" and defaults to US values as anticipated
(no offense EMEA!). Also we included *locale *and preferred units* *in Get-User-Info call, so any application could be aware of the origin of the particular user to improve API
interaction, preferred unit system or even UI language, based on her preference.
We have extended *time series* resources with couple more* "clean" resources **from the tracker*
(http://wiki.fitbit.com/display/API/API-Get-Time-Series). This includes *activityCalories *and
breakdown of *active minutes* for a particular date.
A considerable amount of small improvements, and among them:
* *mets* value in Get-Activity, Browse-Activities, Get-Favorite-Activities,
* the list of all *food servings* in Get-Food, Get-Favorite-Foods,
* *body fat *interpolation in Get-Time-Series calls, and* body fat goal *in Get-Body-Measurements,
* *memberSince *in Get-User-Info,
* new* food plan* support in the goals section of Get-Foods call.
As usual for those of you who is close to Java development, we updated the Fitbit4J library
to the most recent version 1.0.22 some time ago, and anticipate to release 1.0.23 in the next
couple of weeks.
