Whoop API Integration | Open Wearables

Need help with your Whoop integration? Pop into our Discord if you have questions or want to discover how Open Wearables can solve your problems.

Overview

Whoop provides access to workout, sleep, recovery, and body measurement data through their REST API. The integration uses OAuth 2.0 for authentication and pull-based syncing to fetch data.

Supported data types

Data Type	Support
Workouts / Activities	Yes
Sleep (with stages)	Yes
Recovery (score, resting HR, HRV, SpO2, skin temp)	Yes
Body measurements (height, weight)	Yes
Continuous heart rate / activity samples	No (not available via API)

Data delivery

Method	Description
Polling (pull)	Open Wearables periodically fetches workout, sleep, recovery, and body measurement data via the Whoop API (default: every hour via Celery Beat)

Webhooks: Whoop supports webhooks for workout, sleep, and recovery events (created, updated, deleted). Open Wearables does not yet implement a Whoop webhook handler — data is currently synced via periodic polling only. Webhook support is planned for a future release.

What you need by the end

App credentials: Client ID + Client Secret
OAuth scopes configured
Redirect URI registered in the Whoop Developer Dashboard

Prerequisites

A Whoop account with an active membership

Application walkthrough

You must have a Whoop membership to develop on the Whoop Developer Platform. Your Whoop account is also your developer login.If you don’t have one yet, join Whoop here.

Create a Team in the Developer Dashboard

Go to the Whoop Developer Dashboard and sign in with your Whoop account credentials.Before creating an app, you’ll be prompted to create a Team. Choose a name for your team and click Create Team.

You can invite other developers to your team later from the Team section of the Developer Dashboard. They’ll need a Whoop account to be added.

Create an App

In the Developer Dashboard, go to the app creation flow:

App Name: Your application name
Scopes: Select the scopes your app needs (see table below)
Redirect URIs: Add your OAuth callback URL (e.g. http://localhost:8000/api/v1/oauth/whoop/callback for local development)

After creating the app, you’ll receive:

Client ID
Client Secret

Your Client Secret should never be logged or shared. It should only be used server-side and never exposed in client, web, or mobile applications.

Configure credentials in Open Wearables

Add the following to your .env file:

#--- Whoop ---#
WHOOP_CLIENT_ID=your-whoop-client-id
WHOOP_CLIENT_SECRET=your-whoop-client-secret
WHOOP_REDIRECT_URI=http://localhost:8000/api/v1/oauth/whoop/callback
WHOOP_DEFAULT_SCOPE=offline read:cycles read:sleep read:recovery read:workout

Configuration details:

Variable	Description
`WHOOP_CLIENT_ID`	Client ID from the Whoop Developer Dashboard
`WHOOP_CLIENT_SECRET`	Client Secret from the Whoop Developer Dashboard
`WHOOP_REDIRECT_URI`	Must match a redirect URI registered in the Developer Dashboard. For local dev: `http://localhost:8000/api/v1/oauth/whoop/callback`
`WHOOP_DEFAULT_SCOPE`	OAuth scopes requested during authorization. The `offline` scope is required for refresh tokens

Connect a user via OAuth

With credentials configured and your Open Wearables instance running, initiate the OAuth flow to connect a user’s Whoop account.1. Get the authorization URL:

curl -X GET "http://localhost:8000/api/v1/oauth/whoop/authorize?user_id={user_id}&redirect_uri=http://localhost:3000/users/{user_id}" \
  -H "X-Open-Wearables-API-Key: YOUR_API_KEY"

Response:

{
  "authorization_url": "https://api.prod.whoop.com/oauth/oauth2/auth?client_id=...&redirect_uri=...&response_type=code&scope=offline+read%3Acycles+read%3Asleep+read%3Arecovery+read%3Aworkout&state=...",
  "state": "abc123..."
}

2. Redirect the user to the authorization_url. They will log in to Whoop and authorize your app.3. Whoop redirects back to the callback URI configured in your .env (WHOOP_REDIRECT_URI). Open Wearables automatically exchanges the authorization code for access and refresh tokens.4. Verify the connection was created:

curl -X GET "http://localhost:8000/api/v1/users/{user_id}/connections" \
  -H "X-Open-Wearables-API-Key: YOUR_API_KEY"

You should see a connection with "provider": "whoop" and "status": "active".

The redirect_uri parameter in the authorize call is where the user is sent after the flow completes (e.g., back to your app). This is separate from WHOOP_REDIRECT_URI in your .env, which is the server-side OAuth callback that Whoop sends the authorization code to.

Sync data

An initial sync is triggered automatically after a successful OAuth connection. To manually sync or fetch historical data:

# Sync all data types
curl -X POST "http://localhost:8000/api/v1/providers/whoop/users/{user_id}/sync?data_type=all" \
  -H "X-Open-Wearables-API-Key: YOUR_API_KEY"

You can also sync specific data types:

# Sync only workouts
curl -X POST "http://localhost:8000/api/v1/providers/whoop/users/{user_id}/sync?data_type=workouts" \
  -H "X-Open-Wearables-API-Key: YOUR_API_KEY"

# Sync only sleep & recovery
curl -X POST "http://localhost:8000/api/v1/providers/whoop/users/{user_id}/sync?data_type=247" \
  -H "X-Open-Wearables-API-Key: YOUR_API_KEY"

When no date range is specified, Whoop defaults to syncing the last 30 days of data.

Verify the integration

Once data has synced, fetch it via the Open Wearables API:

# Fetch workouts
curl -X GET "http://localhost:8000/api/v1/users/{user_id}/events/workouts?start_date=2026-01-01T00:00:00Z&end_date=2026-02-01T00:00:00Z" \
  -H "X-Open-Wearables-API-Key: YOUR_API_KEY"

# Fetch sleep sessions
curl -X GET "http://localhost:8000/api/v1/users/{user_id}/events/sleep?start_date=2026-01-01T00:00:00Z&end_date=2026-02-01T00:00:00Z" \
  -H "X-Open-Wearables-API-Key: YOUR_API_KEY"

If data is returned, your Whoop integration is working end-to-end.

Submit your app for production (when ready)

While developing, your app works in development mode. When you’re ready to launch:

Go to the Developer Dashboard
Submit your app for approval

Rate Limits

Whoop applies two rate limits by default:

Limit	Value
Per minute	100 requests
Per day	10,000 requests

How Open Wearables uses the quota: Each sync cycle per user makes ~4-7 API requests (workouts, sleep, recovery, and body measurements — each paginated at 25 items per page). With the default polling interval of 1 hour, that’s roughly ~120 requests per user per day. This means the default rate limits comfortably support ~60-80 connected users per app. If you need to support more users right now, you can request increased rate limits from Whoop via the Developer Dashboard.

We’re working on optimizing the sync strategy (webhook-based updates instead of periodic polling, smarter pagination) to significantly increase the number of supported users without requiring a rate limit increase from Whoop.

OAuth Scopes Reference

Scope	Description
`offline`	Required to receive refresh tokens for long-lived access
`read:cycles`	Read physiological cycle data
`read:sleep`	Read sleep data (sessions, stages, efficiency)
`read:recovery`	Read recovery data (score, resting HR, HRV, SpO2, skin temp)
`read:workout`	Read workout/activity data
`read:body_measurement`	Read body measurements (height, weight)
`read:profile`	Read user profile information

The default scope offline read:cycles read:sleep read:recovery read:workout covers all data types currently processed by Open Wearables.

Next Steps

API Reference

Explore the Open Wearables API endpoints.

Architecture

Understand the overall system architecture.

Support

Need Help?

Join our Discord and ask a question.
Check GitHub Discussions.
Check the Whoop Developer Documentation.

Getting started

Architecture

Providers

Open Wearables Mobile App

Sync SDK

MCP Server

Developer Guides

Configuration

Deployment

Support

Whoop API Integration | Open Wearables

Overview

Supported data types

Data delivery

What you need by the end

Prerequisites

Application walkthrough

Rate Limits

OAuth Scopes Reference

Next Steps

API Reference

Architecture

Support

Getting started

Architecture

Providers

Open Wearables Mobile App

Sync SDK

MCP Server

Developer Guides

Configuration

Deployment

Support

​Overview

​Supported data types

​Data delivery

​What you need by the end

​Prerequisites

​Application walkthrough

​Rate Limits

​OAuth Scopes Reference

​Next Steps

API Reference

Architecture

​Support

Overview

Supported data types

Data delivery

What you need by the end

Prerequisites

Application walkthrough

Rate Limits

OAuth Scopes Reference

Next Steps

Support