Wearable API:
Different devices. A deliberate data model.

Choose the boundary your application owns

Your application might read an operating system health store, integrate a manufacturer’s account, or communicate with a nearby sensor. These are different boundaries with different permissions and failure modes. Compare the records available, update timing, user setup steps, and maintenance work for each option. A platform store may reduce the number of direct integrations, but it does not guarantee every field from every device.

Normalize units without erasing context

A common schema should preserve both the normalized measurement and its origin. Keep source identifiers, source timestamps, observation intervals, and your ingestion time. Store the original unit or conversion rule where it helps explain a transformation. Do not silently merge an estimated daily summary with a direct sensor sample. Your interface can be simple while the underlying records retain enough detail to resolve disagreements.

Design synchronization as a recoverable process

Plan for interrupted permissions, duplicate delivery, delayed sync, and corrected historical records. Use stable source identifiers when they exist. Persist an explicit synchronization checkpoint rather than assuming the most recent visible record marks a complete import. Decide whether a record is new, corrected, deleted, or merely redelivered. Make the user’s connection status understandable without exposing internal error codes.

Make your first integration plan

Use the Docs and illustrative record examples to turn these questions into a small data contract. Then review the integration cost checklist before expanding device coverage. The goal is a first implementation whose assumptions are visible and testable.