Overview
This guide walks you through the complete integration of the Open Wearables Android SDK into a native Kotlin application, from backend setup to production deployment.1
Set up backend authentication endpoint
2
Initialize and configure the SDK
3
Implement sign-in flow
4
Select health provider
5
Request health permissions
6
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 Android app receives the tokens and passes them to
sdk.signIn(accessToken, refreshToken).SDK stores & syncs
Android SDK stores credentials in EncryptedSharedPreferences and uses
accessToken to sync health data directly to Open Wearables.Building a standalone app with no backend of your own? Invitation codes are an alternative - a single-use code the app redeems directly, no backend channel required. This is not the standard flow; it exists mainly for the Open Wearables app and the example apps. If your app authenticates users against your own backend (the normal case), use the backend token flow above. See Choosing an onboarding flow.
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 Initialization & Configuration
Initialize the SDK once in yourApplication class or main activity, then configure it with your backend host.
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 credentials from EncryptedSharedPreferences: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):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: Select Health Provider
Before requesting permissions, you must select a health data provider:Call
setProvider() before requestAuthorization(). The SDK needs to know which provider to request permissions from.Provider Comparison
Step 5: Request Permissions
Request access to specific health data types. The type IDs are string-based:Make sure to call
setActivity() on the SDK before requesting authorization, so the SDK can launch the permission dialog from the correct Activity context.Step 6: 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
Manual Sync
Trigger an immediate sync:Stop Sync
Log Level
Control SDK log output using thelogLevel property. By default, the SDK uses OWLogLevel.DEBUG, which outputs logs only in debuggable builds:
Lifecycle Management
Notify the SDK of app lifecycle changes for optimal sync behavior:Complete Integration Example
Here’s a complete ViewModel showing the full integration:Using the ViewModel
Data Sync Endpoint
The SDK sends health data to:provider field ("samsung" or "google") and the SDK version:
Next Steps
Troubleshooting
Common issues and solutions for Android.
Data Types
Available health metrics and data formats.

