It’s been almost a year since we launched the Health Graph API. We’ve learned a lot, and based on that learning, we’re making some changes to our API policy to make it more user-friendly and more partner-friendly as we continue to grow.
A bit of history
The goal of the Health Graph is to give consumers one place to store, correlate, and understand their Health and Fitness data. Two of our core beliefs around achieving this goal:
- Users should have control over their own data.
- Data integrity is paramount to providing meaningful insights.
As a part of our implementation of these beliefs, a core tenet of our existing API policy has been that when a user disconnected their account from a third party partner application, service, or device, that partner has been required to remove all data that had previously been read from the Health Graph on that user’s behalf. The idea being that by requiring partners to remove that data, we were insuring that user data didn’t become siloed somewhere against their wishes.
Why change?
While our core beliefs around data control (users should be empowered) and data integrity (everything should be kept in sync) haven’t changed, we’ve learned that our execution on them wasn’t perfectly aligned with the needs of users or partners.
- For users, we didn’t provide an efficient mechanism for them to export their data out of our system.
- For partners, the relationship wasn’t reciprocal – data written to the Health Graph was stored until a user explicitly deleted it, while data read from the Health Graph could only be cached as long as a user maintained a partner app’s authorization.
- For both parties, the policy meant that disconnecting from the Health Graph had the potential to destroy the experience for users with the partner’s application.
What’s changing:
We recently addressed the first user concern by providing an easy mechanism for users to export data from their RunKeeper account. We’ve been receiving and implementing great user feedback on the export functionality; please keep it coming!
Now we’re addressing the additional concerns around data retention through an updated API policy and new functionality to support these updates.You can read the entire policy here, but the primary update boils down to this: If a user gives a partner permission upon disconnecting their service from the user’s Health Graph account, that service can retain any Health Graph data they have previously cached on that user’s behalf, indefinitely.
How this change works in practice:
When a user goes to disconnect a service from the Health Graph, they are now prompted to confirm this disconnection in a modal window (see below). As part of this confirmation, they are also given a choice of allowing the partner to keep data previously obtained through the Health Graph.
Image may be NSFW.
Clik here to view.
The user’s choice is passed through as part of the deauthorization callback described here.
What about my (Existing) integration?
Nothing has to change with your application. If you had previously requested permission to read data from the Health Graph, you can cache Health Graph data and remove it when a user disconnects. However, if you would like to take advantage of our updated terms around data retention, you’ll need to make a couple small changes to understand a user’s data retention request via the updated callback, or new deauthorization service mentioned in the previous section. You’ll also need to update your application settings to enable this data retention request.
One more thing…
We also totally revamped our Health Graph support docs. While the aesthetic changes are great, we’re really happy to be including basic search functionality, improved readability, and better access to our developer resources. Stay tuned, because a functional developer console is coming soon as well.
Thank you for all of the great feedback you have provided, which led to these improvements. Feel free to provide any additional feedback in the comments below. We can’t wait to see all of the great integrations that are to come!
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
