General
Overview
This document focuses on the difference between SDK based providers and all other, most commonly following Oauth 2 flow.
Common principles
SDK based integrations (Apple Health Kit, Android Health Connect and Samsung Health Data) have a few common principles that separates them from all other providers.- Data is stored only on the device (phone) therefore requires to be actively extracted
- Permission control is very granual (each metric reading requires approval)
- Data becomes available instantly as it’s recorded
- Integration requires active management through SDKs
Creating integrations
Creating these integration do not follow Oauth path. Meaning- there will be no redirecting to provider authorisation page,
- and therefore no callback URL post permission grant.
- Permissions are granted locally, on the phone it self, by triggering SDK methods.
- Permissions are also managed by default OS schemas, application users navigating settings menus, are granted for application package (reinstalling the app might require reauthorisation), can be revoked or ignored when requested by OS based on their policies.
Data extraction
Data stored only on user mobile device’s local hardware (encrypted at rest). In order to make data available over API, first you must select and call SDK functions dedicated for sleep, workouts or other metrics reading. Schema below should explain the flow and explain the sequence of events, the moment when data becomes available for reading over API and SDK.Events sequence schema
