Skip to main content
Data flow diagram: a wearable device syncs through the provider app to the provider cloud, which Open Wearables pulls from or receives webhooks from; mobile-only sources reach Open Wearables through the SDK instead. Open Wearables normalizes everything into the unified data model and serves it to your backend over the REST API and outgoing webhooks, and to AI assistants through the MCP server.

​
Cloud providers

Garmin, Polar, Oura, Whoop, Suunto and other cloud-based providers:
  1. Wearable device collects data with its sensors.
  2. Provider app on the user’s phone reads the data from the device over BLE.
  3. Provider cloud receives the data when the app syncs.
  4. User authorizes your app to access their data via OAuth. The flow is started through Open Wearables - see the integration guide.
  5. Open Wearables keeps the data in sync and normalizes it into the unified data model. Every provider uses one of two methods:
    • push - the provider sends a webhook as soon as new data is available, and Open Wearables fetches it immediately.
    • pull - Open Wearables polls the provider on a schedule (hourly by default, SYNC_INTERVAL_SECONDS), because the provider offers no webhooks.
    Which method a provider uses is a property of that provider, not something you configure per user.
  6. Your backend queries the data through the REST API with an API key, or receives outgoing webhooks when new data arrives.
  7. Your frontend talks to your backend to display the data.

​
Historical backfill

Push and pull only cover data recorded from the moment the user connects. Everything older needs a one-off historical backfill - a separate job, triggered explicitly:
How far back you can go depends on the provider - see historical data limits. For now it also fires automatically after every successful OAuth callback. You control this with HISTORICAL_SYNC_ON_CONNECT in the backend environment (default true) - set it to false to trigger backfill yourself. The automatic dispatch is a leftover that will go away, so don’t build on it.

​
Mobile-only sources

Apple Health, Samsung Health and Health Connect keep data in an on-device store and have no cloud API, so they can only be read from the user’s phone. Instead of steps 3-5, your mobile app uses the Open Wearables SDK to read the data and push it to Open Wearables in the background. From there the flow is the same.

​
AI assistants

The MCP server exposes the same data to AI assistants such as Claude or Cursor, using the REST API under the hood.