Overview
This guide walks you through the complete integration of the Open Wearables Flutter SDK, from backend setup to production deployment.1
Set up backend authentication endpoint
2
Configure the SDK in your Flutter app
3
Implement sign-in flow
4
Request health permissions
5
Start background sync
Authentication Architecture
The SDK supports two authentication modes: token-based (recommended) and API key. The token-based flow keeps your App credentials safe on your backend:Your Backend generates token
Your backend calls the Open Wearables API with your App credentials (
app_id + app_secret) to generate a user-scoped token (server-to-server, HTTPS) via Create User Token endpoint. Open Wearables returns access_token + refresh_token.Your Backend returns tokens to the app
Your backend exposes its own custom endpoint that forwards the
access_token and refresh_token to the mobile app. Never expose app_id or app_secret to the client.Mobile App calls SDK signIn
The Flutter app receives the tokens and passes them to
OpenWearablesHealthSdk.signIn(accessToken, refreshToken).SDK stores & syncs
Flutter SDK stores credentials in iOS Keychain / Android EncryptedSharedPreferences and uses
accessToken to sync health data directly to Open Wearables.Step 1: Backend Setup
Your backend needs a single endpoint that generates access tokens for your users by calling the Open Wearables API and forwarding the tokens.Generate Access Token
When a user wants to connect their health data, your backend should:- Authenticate the user (your own auth system)
- Call Open Wearables API at
POST /api/v1/users/{user_id}/tokenwith your App credentials - Return the
access_tokenandrefresh_tokento the mobile app
- Node.js
- Python
- Ruby
The
user_id in the URL is the Open Wearables User ID (UUID). You should store this mapping in your database when you first Create User via the Open Wearables API.Step 2: SDK Configuration
Configure the SDK once at app startup, typically in your main initialization code.Configuration Options
Provide only the base host URL, e.g.
https://your-domain.com. Do not append /api/v1/ or any other path — the SDK adds the required path prefix automatically.Session Restoration
The SDK automatically restores the user session from secure storage whenconfigure() is called:
Step 3: Sign In
After getting credentials from your backend, sign in with the SDK:The
userId parameter is the Open Wearables User ID (UUID) — the id returned by the Create User endpoint. Do not pass your own external_user_id here.Token-Based Authentication (Recommended)
API Key Authentication
For simpler setups (e.g. internal tools), you can use API key authentication directly:Automatic Token Refresh
When you provide arefreshToken, the SDK automatically handles 401 responses by refreshing the access token and retrying the request.
You can also update tokens manually:
Step 4: Request Permissions
Request access to specific health data types:Android Provider Selection
On Android, you must select a health data provider before requesting authorization:On iOS, users can grant partial permissions. The SDK will sync whatever data the user allows.
Step 5: Start Background Sync
Enable background sync to keep data flowing even when your app is in the background:Controlling Sync History Depth
By default, the SDK syncs all available historical data on the first sync. Use thesyncDaysBack parameter to limit how far back the sync goes:
Background Sync Behavior
- iOS
- Android
Manual Sync
Trigger an immediate sync when needed:Log Level
Control SDK log output usingsetLogLevel. By default, the SDK uses OWLogLevel.debug, which prints logs only in debug builds:
Complete Integration Example
Here’s a complete service class showing the full integration:Using the Service
Data Sync Endpoint
The SDK sends health data to:Your Open Wearables API base URL (e.g.
https://api.example.com).The user ID returned when registering the SDK user.
Next Steps
Troubleshooting
Common issues and solutions for iOS and Android.
Data Types
Available health metrics and data formats.

