October 2014 Fitbit API Updates and Deprecations

[JeremiahFitbit]

Heart Rate, GPS, and OAuth 2.0 Coming Soon

Today, Fitbit announced three exciting new products: Charge, Charge HR, and Surge. We're also excited to announce that the Fitbit API will provide access to the all day heart rate and GPS data from these devices. These data types will be accessible exclusively via OAuth 2.0. We'll be sharing more information about these new endpoints and our OAuth 2.0 transition in the coming months.

HTTPS Required on November 3, 2014

As announced in August, connections to api.fitbit.com will be restricted to HTTPS connections on November 3, 2014. TLS will be required on all api.fitbit.com endpoints, including all steps of OAuth.

TLS creates a secure communication channel between your application and Fitbit's API, ensuring user data is not accessed or tampered by unauthorized parties. If your application uses HTTP plaintext connections, you need to update it to use HTTPS immediately. Applications still using HTTP plaintext connections will stop functioning on November 3, 2014. The Fitbit API will return a HTTP 403 error to all non-TLS requests.

For most applications, changing "http://" to "https://" is all that is necessary to comply with this change.

Deprecations

XML

Less than 5% of third-party Fitbit API requests are using XML. Going forward, new endpoints will be optimized for and exclusively available in JSON.

Custom Logging Endpoints

The following API endpoints are deprecated and will be removed at a future date:

• API-Get-Heart-Rate (will be replaced with heart rate time series endpoints)
• API-Log-Heart-Rate
• API-Delete-Heart-Rate-Log
• API-Get-Blood-Pressure
• API-Log-Blood-Pressure
• API-Delete-Blood-Pressure-Log
• API-Get-Glucose
• API-Log-Glucose
• API-Get-Body-Measurements
• API-Log-Body-Measurements

All measurements except fat and weight will be removed from:

• API-Get-Body-Measurements
• API-Log-Body-Measurements

If you have questions about this notice, please post here.

–The Fitbit API Team

[Matt]

Awesome stuff. Looking forward to switching to OAuth 2.0!

[Michael]

---

@JeremiahFitbit wrote:

All measurements except fat and weight will be removed from:

• API-Get-Body-Measurements
• API-Log-Body-Measurements

---

@JeremiahFitbit I thought that the extra measurements were going to be maintained and still available for us by existing users, just that new users wouldn't be able to use them. Is that not going to be the case with the APIs?

[JeremiahFitbit]

---

@Michael wrote:

@JeremiahFitbit I thought that the extra measurements were going to be maintained and still available for us by existing users, just that new users wouldn't be able to use them. Is that not going to be the case with the APIs?

---

Marking these endpoints as deprecated means that we're not planning future development of them and that third-party developers should not create new integrations with them.

[Michael]

---

@JeremiahFitbit wrote:

---

@Michael wrote:

@JeremiahFitbit I thought that the extra measurements were going to be maintained and still available for us by existing users, just that new users wouldn't be able to use them. Is that not going to be the case with the APIs?

---

Marking these endpoints as deprecated means that we're not planning future development of them and that third-party developers should not create new integrations with them.

---

But your announcement doesn't just say they will be marked as deprecated, it says that the additional measurements will be removed from them. That is a big difference.

[cwayne18]

When can we expect to be able to switch over to Oauth 2.0?

[SetpointHealth]

Why in the world would you depreciate XML? Does it really add that much overhead on your side that you're goign to make 5% of us change our code?

[ibahdanau]

Here at Fitbit we focused on providing as much easy-to-use API for developers as it possilbe. Our aim is that all developers who use Fitbit API can easy understand data structure even without reading documentation.

Due to different natures of JSON and XML we are required now to have two different serialization approaches: one for JSON and other one for XML. 

Since most of our users are using JSON(around 98%) and we decided to focus and polish JSON serialization and deprecate XML. 

Overall ourdays development community tends to get rid of XML since there are more advantages of JSON over XML then XML over JSON. 

[Chetan]

Hi Jeremiah,

When you say "OAuth 2.0 transition", do you still intend to support OAuth 1.0 in the near future? Is there a timeline when you intend to stop supporting 1.0?

Thanks.

[JeremiahFitbit]

---

Chetan wrote:

When you say "OAuth 2.0 transition", do you still intend to support OAuth 1.0 in the near future? Is there a timeline when you intend to stop supporting 1.0?

---

We do not plan on deprecating OAuth 1.0a for quite awhile.

[JeremiahFitbit]

---

@SetpointHealth wrote:

Why in the world would you depreciate XML? Does it really add that much overhead on your side that you're goign to make 5% of us change our code?

---

Actually, yes, supporting both XML and JSON does add notable overhead when done properly. It's impossible to programatically optimize responses in both JSON and XML.

This announcement does NOT require you to change your code. All existing endpoints will continue to support XML.
However, when you want to take advantage of the new features and endpoints that we haven't announced yet, you'll need to use JSON.

[Starlight71701]

I would like to know if the Charge Hr will be waterproof like the Flex ?  

[SunsetRunner]

---

@Starlight71701 wrote:

I would like to know if the Charge Hr will be waterproof like the Flex ?  

---

Hi, you have posted in the incorrect forum; we talk about the Fitbit API in here. Please post in the Charge HR forum https://community.fitbit.com/t5/Charge-HR/bd-p/chargeHR

Thanks!

[Rabin]

Will there be an Api for direct BLE communication for windows phone?

[ibahdanau]

There are no plans on sadding upport for direct BLE communication API.

[LGFox]

Good day!

When you intend to release a new version of Fitbit API? The first half of 2015?

We are looking forward to.

[JeremiahFitbit]

Several people have asked about GPX and TCX export. The API will support TCX export, as it allows us to combine GPS and heart rate data. The GPX format is being considered.

We know that you want this feature now and we can't wait to share it. Given the more sensitive nature of GPS, this export will be an OAuth 2 feature and apps will have to ask for explicit permission. When we have our OAuth 2 ready for beta testing, you'll be able to start using this feature.

[MarkG76]

@JeremiahFitbit  how about an export feature through the web interface for both TCX and GPX?

[m2web]

Any time frame on the TCX export?

[antikewl]

"the Fitbit API will provide access to the all day heart rate and GPS data from these devices"

I'm a bit confused by this. Will the API provide access to data from individually logged runs, or just a total for the whole day?