Skip to main content

Overview

This guide walks you through the complete integration of the Open Wearables React Native SDK, from backend setup to production deployment.
1

Set up backend authentication endpoint

2

Configure the SDK in your React Native 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 API keys 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 React Native app receives the tokens and passes them to OpenWearablesHealthSdk.signIn(accessToken, refreshToken).

SDK stores & syncs

React Native SDK stores credentials in iOS Keychain / Android EncryptedSharedPreferences and uses accessToken to sync health data directly to Open Wearables.
Never embed your app_id / app_secret in the mobile app. App credentials should only exist on your backend server. Only the access_token and refresh_token are passed to the mobile app.
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 React Native example app. 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:
  1. Authenticate the user (your own auth system)
  2. Call Open Wearables API at POST /api/v1/users/{user_id}/token with your App credentials
  3. Return the token to the mobile app
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

Session Restoration

On app startup, call getStoredCredentials() to retrieve any previously saved session. If a host is stored, pass it to configure(), then check isSessionValid() to decide whether a fresh sign-in is needed:

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.

API Key Authentication

For simpler setups (e.g. internal tools), you can use API key authentication directly:
API key authentication embeds the key in the app. Only use this for internal or trusted applications. For production apps, always use token-based authentication.

Automatic Token Refresh

When you provide a refreshToken, 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:
On iOS, users can grant partial permissions. The SDK will sync whatever data the user allows.
Request only the data types you actually need. Requesting too many types can overwhelm users and reduce acceptance rates.

Android Provider Selection

On Android, you must select a health data provider before requesting authorization. Call getAvailableProviders() to list what is installed on the device, then call setProvider(id) with the chosen provider’s id.
Persist the selected provider ID so the user’s choice survives app restarts. Use @react-native-async-storage/async-storage for bare React Native projects, or AsyncStorage from expo-secure-store for Expo apps (though a plain key like a provider ID doesn’t require encryption — AsyncStorage is sufficient).
getAvailableProviders() returns an empty array on iOS — provider selection is not needed there, as HealthKit is the only source.

Step 5: Start Background Sync

Enable background sync to keep data flowing even when your app is in the background:

Background Sync Behavior

Background sync frequency is managed by the OS and may vary based on battery level, network conditions, and user behavior.

Manual Sync

Trigger an immediate sync when needed:

Log Level

Control SDK log output using setLogLevel. By default, the SDK uses OWLogLevel.debug, which prints logs only in debug builds:
Set OWLogLevel.always during development or when troubleshooting sync issues in production. Switch to OWLogLevel.none if you want to suppress all SDK output.

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:
string
required
Your Open Wearables API base URL (e.g. https://api.example.com).
string
required
The user ID returned when registering the SDK user.
Data is automatically normalized to the Open Wearables unified data model and can be accessed through the standard API endpoints.

Next Steps

Troubleshooting

Common issues and solutions for iOS and Android.

Data Types

Available health metrics and data formats.