One of the presentations I give frequently is a talk on Quantifying your Fitness. In doing research for this topic, I’ve worked with devices and APIs for a multitude of systems. Everyone has their favorite device, and I want to give some reasons to consider the Fitbit family of products as a great tool for anyone who wants to integrate their fitness into other parts of their lives.
Most fitness trackers integrate with closed systems - the Apple Watch, which I love, unfortunately only integrates with the Apple Health application. It’s my data, I created it with my body, but I am contracturally disallowed from getting data out of the system to use it as I want - whether that’s integrating with other applications, making cool graphs and charts, integrating with IFTTT, or anything else. Yes, many of the devices out there are “open source,” but that means something very different to me than it does to the makers. If the system only allows me to integrate with a device I own, and I’m not allowed to access the data from the cloud, I consider it a closed system.
So, Fitbit. There are a variety of reasons why their devices and API are consistently featured in my talks. Here are some of the things I’ve come to appreciate with their system in comparison to their competitors.
Long term prospects
One of the biggest concerns when integrating with a new system is wondering whether or not the system will be around for the long haul. Too many times, APIs have been spawned, and because of business concerns or simple changes in direction, those APIs disappear into the ether, leaving your integrations out in the cold. The Fitbit API is a large part of Fitbit’s strategy - they have put a lot of resources into development, they have developer evangelists and a vibrant community, and the sheer number of integrations they support demonstrates their commitment to keeping the API around for the long term. Contrast this with Runkeeper, a fine API with a great design, but I’m unsure that their business model will be strong enough to keep them alive and kicking. Give me a stable, strong company with a clear business model any day.
Fitbit’s API covers not just the items their trackers track, such as steps, calories and heartrate, but also things like glucose, blood pressure, and other biometrics. Someday perhaps they’ll have trackers for these items, but in the meantime it’s possible to use their API as a grand central station of health information, and as a maker or hacker, this means that you can combine information into a single place for consumption, whether you want to explore the measurements or simply have them stored away for future use.
Integrating with a fitness device is much less useful if you can’t get notified when there’s a change to the data. Fitbit’s publication model allows API developers to listen for changes in any of the measurement types so they can create actions based on the change - for instance, as I go through the day, I use my philips hue lights to reflect my progress in activity and food logging.
API Developer Experience
The developer experience for this API is really quite excellent.
- They’ve got good documentation
- The signup flow is relatively painless
- Their evangelists answer questions in the active forum
- Nice sample code and integration examples
I always say that the developer experience is one of the main drivers for an API’s success, and Fitbit does an excellent job of making this pleasant.
Sure, I like writing code. I have an app that sends me SMS messages and updates my philips hue lightbulbs based on how my activity is going throughout the day. But for a regular maker/hacker, sometimes IFTTT is just fine, and the existing integrations that Fitbit has created and maintained make it painless to add a variety of different notifications and behaviors based on your progress. I like that I can use my withings scale and blood pressure monitor to put more information into the system. I’m looking forward to the day when there’s a glucose monitoring watch that also integrates with Fitbit. It’s unfortunate that Fitbit and Apple couldn’t agree on integrations together, but I suspect it had to do with the fact that Apple wants to own all the data going into the system and that’s not the model Fitbit uses. I prefer having my own access to my own data and it rankles a bit that I can’t get it from the Apple ecosystem.
I’ll likely write up a few more reviews of other fitness devices presently, but this one really focuses on integration and application development. If you want to interact with your biometric data in a custom manner, or just work with a system that allows you to pull down the information you’ve generated for whatever reason, you should almost certainly go with Fitbit. They’ve got a ton of different trackers - the one I currently like the best is the Fitbit Charge 2, as it has heart rate monitoring, some SMS functionality, and is generally small enough not to be annoying.
Let me know if this is useful for folks, and I’ll keep writing more about various APIs and integrations going forward.