How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers

Open Wearables Team · July 21, 2026 · 6 min read

Key Takeaways

Every wearable provider implements OAuth differently. Garmin uses OAuth 2.0 with PKCE. Polar, Suunto, Strava, Oura, and Whoop also use OAuth 2.0. Apple Health does not use OAuth at all and requires a mobile SDK.
Data delivery models differ per provider. Garmin pushes full payloads via webhook stream and supports webhook callback for historical backfill. Whoop, Oura, Polar, and Strava send lightweight webhook pings that trigger a follow-up REST pull.
Token refresh is handled automatically by Open Wearables for all OAuth providers. Your application code does not manage token expiry.
Open Wearables implements OAuth state validation with PKCE support, Redis-backed state storage with a 15-minute TTL, and structured logging for every auth event.
Your application triggers the authorization flow with a single redirect. Open Wearables handles the OAuth handshake, token storage, and ongoing sync.

Building wearable integrations looks straightforward until you try to support more than one provider. Each provider has a different OAuth variant, a different mechanism for delivering data to your backend, and different token lifecycle rules. What works for Polar does not apply to Garmin. What works for Garmin does not apply to Apple Health at all.

This article describes what each major provider requires, how Open Wearables abstracts those differences, and what you still need to handle in your application.

OAuth Across Providers

All cloud-based providers in Open Wearables use OAuth 2.0. The flows share the same structure but differ in scopes, token expiry, and optional security extensions.

Garmin uses OAuth 2.0 with PKCE (Proof Key for Code Exchange). PKCE is a security extension that prevents authorization code interception attacks. Open Wearables handles the PKCE code challenge and verifier generation automatically.

Polar, Suunto, Strava, Oura, Whoop, and Fitbit use standard OAuth 2.0 without PKCE. Each has its own authorization server URL, scope naming conventions, and token format.

Apple Health does not expose a backend API. There is no OAuth flow. Data comes through the HealthKit SDK on the user's iOS device. Your application needs a mobile component using HealthKit to read data and send it to your Open Wearables instance. Open Wearables ships a Flutter SDK for this.

Google Health Connect and Samsung Health are similarly SDK-based on Android. No backend OAuth, no webhook delivery.

The Authorization Flow in Open Wearables

For OAuth-based providers, Open Wearables implements the authorization flow using Redis for state management.

When a user initiates a connection, Open Wearables generates a cryptographically random state token (32 bytes, URL-safe Base64), stores it in Redis with a 15-minute TTL, and constructs the provider's authorization URL. For Garmin, it also generates a PKCE code challenge at this step.

The user is redirected to the provider's login page, approves access, and is sent back to the Open Wearables callback endpoint with an authorization code. Open Wearables validates the state against Redis, exchanges the code for access and refresh tokens, fetches the user's provider profile, and saves the connection.

Your application triggers this with a single call to the Open Wearables authorize endpoint:

            GET /api/v1/oauth/{provider}/authorize?user_id={user_id}

Open Wearables returns the provider authorization URL. Your frontend redirects the user there. The rest of the handshake happens inside Open Wearables.

How Data Gets to Your Backend

After authorization, data delivery depends on the provider's architecture. Open Wearables handles all delivery models transparently, but understanding them helps when debugging sync issues.

Webhook stream (Garmin): The provider pushes the complete data payload directly to a registered webhook endpoint. Open Wearables receives, processes, and normalizes the payload. Garmin uses this model for live sync.
Webhook callback (Garmin historical backfill): You initiate a REST request asking the provider to export data for a time range. The provider processes the request asynchronously and pushes the result to your registered webhook.
Webhook ping with REST pull (Whoop, Oura, Polar, Strava): The provider sends a lightweight notification indicating new data is available. Open Wearables receives the ping, then makes a follow-up REST call to fetch the actual data.
Mobile SDK (Apple Health, Google Health Connect, Samsung Health): Data flows from the device to your Open Wearables instance through the SDK client.

In practice this means a user connected to both Garmin and Strava has data arriving through two entirely different architectures simultaneously. Open Wearables normalizes both into the same EventRecord and DataPointSeries model. Your application queries the same endpoints regardless of which provider the data came from.

Token Refresh Across Providers

Token expiry and refresh is one of the most common sources of production bugs in wearable integrations.

Open Wearables handles token refresh automatically for all OAuth providers. When a sync attempt encounters an expired token, the platform uses the stored refresh token to obtain a new access token before retrying. Your application code does not see expired tokens or handle refresh logic.

Open Wearables also implements refresh token rotation: when a refresh token is used, the old one is revoked and a new one is issued. Token data is stored encrypted in your PostgreSQL instance.

What Open Wearables Handles vs. What You Handle

Open Wearables handles:

OAuth state generation, Redis storage, and validation
PKCE for Garmin
Authorization code exchange for access and refresh tokens
Token refresh for all OAuth providers
Refresh token rotation
Webhook endpoint registration with providers that support it (Garmin, Oura, Strava, Polar)
Incoming webhook payload processing and normalization
Celery-based scheduled sync for providers that support polling
Deduplication across providers for the same user

Your application handles:

Triggering the authorization flow (redirect to the Open Wearables authorize endpoint)
Storing your provider API credentials as environment variables in your Open Wearables instance
Applying for developer credentials with each provider
Registering your redirect URI with each provider's developer portal
Querying the normalized Open Wearables API for data

Provider Credential Setup

Open Wearables uses your own developer credentials with each provider. You register your application directly with Garmin, Polar, Strava, and so on, obtain a Client ID and Client Secret, and configure them in your Open Wearables environment. For example, for Strava:

            STRAVA_CLIENT_ID=your_client_id
STRAVA_CLIENT_SECRET=your_client_secret

The full list of required environment variables per provider is documented at docs.openwearables.io/provider-setup. Provider approval timelines vary. Garmin requires Partner Program approval before issuing production credentials. Most other providers issue credentials immediately through a self-service developer portal.

FAQ

Do users need accounts on each wearable platform?

No. Users connect their existing accounts through the OAuth flow. They do not need to create new accounts. The only exception is Apple Health, which requires the Open Wearables mobile SDK rather than a backend OAuth flow.

How long does provider credential approval take?

The Garmin Connect Developer Program is currently not accepting new applications. The official access request form at garmin.com shows: "Stay tuned for more updates on the program." If you are planning an integration that requires Garmin, check the current status at the Garmin developer portal before committing to a timeline. Other providers (Strava, Polar, Oura, Whoop) issue credentials through a self-service developer portal with no approval delay.

What happens when a user revokes access?

The provider stops sending data and returns 401 errors on any sync attempt. Open Wearables detects this and marks the connection as disconnected. The user needs to go through the authorization flow again to reconnect.

Can I use Open Wearables alongside an existing direct provider integration?

Yes. Open Wearables works independently. You can add providers through Open Wearables while keeping existing direct integrations. The unified API means you can gradually migrate or run both in parallel.

Does Open Wearables support outbound webhooks to notify my system when new data arrives?

As of the current release, outbound webhooks from Open Wearables to your backend when new data arrives are on the active roadmap. In the meantime, you can poll the Open Wearables REST API or use the Celery task queue for scheduled processing. Check the GitHub repository for current implementation status.

Back to all posts