Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates to Fitbit's API endpoints for sleep? #26

Open
madprime opened this issue Oct 11, 2019 · 1 comment
Open

Updates to Fitbit's API endpoints for sleep? #26

madprime opened this issue Oct 11, 2019 · 1 comment

Comments

@madprime
Copy link
Member

madprime commented Oct 11, 2019

Looking at this:
https://github.com/OpenHumans/oh-fitbit-integration/blob/master/datauploader/tasks.py

... it seems that the endpoint is going to https://api.fitbit.com/1/user

That prefix is still used for the following:

  • Activity endpoints which have the a format https://api.fitbit.com/1/user/[user-id]/activities/tracker/...
  • Heart endpoints which have the a format https://api.fitbit.com/1/user/[user-id]/activities/heart/...
  • Body & weight endpoints which have the a format https://api.fitbit.com/1/user/[user-id]/activities/body/...

However from the sleep documentation: https://dev.fitbit.com/build/reference/web-api/sleep/

... I see the endpoint seems to be updated to be like https://api.fitbit.com/1.2/user/-/sleep/. (Note the "1.2".)

I was looking into this because I'd like to be collecting the sleep stages data (minute-by-minute information about which "stage" of sleep is occurring), which appears to be available in this new endpoint. (I think the old one is working but deprecated: https://dev.fitbit.com/build/reference/web-api/sleep-v1/ )

@madprime
Copy link
Member Author

There's a temptation to clean up with versioned files and stuff but here’s an approach I think might be lossless and a lot easier.

  1. Add a new JSON key to fitbit_urls that stores all the relevant data from the new endpoint
  2. Fill it in with data into the past.
  3. Leave the old ones in place, and let them keep updating if they can. (Don’t care if it’s redundant.)

I think this is “good enough” as I expect it’s lossless, gets the new data, and allows (further) cleanup at some later date (which I don’t expect to happen, but at least it hasn’t been rendered impossible). It should be backwards compatible as long as something using the data isn't upset by the appearance of a new key (which seems very unlikely).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant