How to Integrate the WHOOP API (2026)

The WHOOP API gives you a member's recovery, strain, sleep, and workout data — the HRV-driven recovery and cardiovascular strain scores WHOOP is known for — through OAuth 2.0 authorization-code consent, then REST pulls and webhooks against the https://api.prod.whoop.com base URL. The one-line how: register an app in the WHOOP Developer Dashboard, run the OAuth flow to get an access token for the scopes you need, and call the /v2/... data endpoints with a Bearer token. Two access facts shape everything below, so read them first.

Two things to know before you start

• Every user needs a paid WHOOP membership. The developer platform and API are free, but WHOOP is hardware plus a subscription (One/Peak/Life). There is no WHOOP data without a device and an active membership — for you and for every end user. If your audience does not already own WHOOP, this is a hard blocker, not a detail.
• A new app is capped at 10 WHOOP members until it is approved. Your app works immediately after registration, but it can only connect up to 10 members. To exceed 10 or ship to production you must submit the app through WHOOP's App Approval flow. Plan for that review before you promise anyone general availability. (Source: developer.whoop.com/docs/developing/app-approval — verify the current cap and process.)

Neither of these is a knock on WHOOP; they are access requirements. If you want a broader wearable strategy or an aggregator that fronts WHOOP alongside others, see wearable data APIs. WHOOP's OAuth flow is close to Oura's, so if you have integrated one the other will feel familiar.

What you'll need

• A WHOOP account and a device with an active membership (to test end to end).
• An app registered in the WHOOP Developer Dashboard (developer.whoop.com), which gives you a client ID and client secret. The secret also verifies webhook signatures — treat it as a server-side secret.
• One or more redirect URIs registered on the app.
• At least one scope selected (an app must request at least one).
• A backend to hold the client secret and do the token exchange. Never run the token exchange or store secrets in a mobile or browser client.

Step 1: Register your app in the Developer Dashboard

In the WHOOP Developer Dashboard, create an app and set:

• Redirect URI(s) — where WHOOP sends the user back with an authorization code.
• Scopes — the data your app can read (see Step 2).
• Webhook URL (optional but recommended) — where WHOOP POSTs update events.

On save you receive a client ID and client secret. The app is live immediately but bound by the 10-member cap until approved.

Step 2: Choose your scopes

Request only what you use. As of 2026 the documented scopes are (verify the current list in the docs):

Include offline if your backend needs to keep syncing after the user closes the app — without it you get no refresh token.

Step 3: Send the user through the OAuth authorize flow

Redirect the user to the authorize endpoint with your client ID, redirect URI, requested scopes, and a state value you generate and later verify (CSRF protection). This is the standard authorization-code grant.

GET https://api.prod.whoop.com/oauth/oauth2/auth
  ?client_id=YOUR_CLIENT_ID
  &redirect_uri=YOUR_REDIRECT_URI
  &response_type=code
  &scope=read:recovery%20read:sleep%20read:workout%20offline
  &state=RANDOM_STATE

The user signs in and consents. WHOOP redirects back to your redirect URI with ?code=...&state=.... Verify state, then move to the token exchange.

Step 4: Exchange the code for an access token

From your backend, POST the authorization code to the token endpoint to get an access_token (and a refresh_token if you requested offline).

# Token exchange
curl -X POST "https://api.prod.whoop.com/oauth/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=THE_AUTH_CODE" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "redirect_uri=YOUR_REDIRECT_URI"

Store the access_token and refresh_token server-side, per user. Access tokens are short-lived; the refresh token lets you mint new ones (see Step 6).

Step 5: Call the data endpoints

With the access token in an Authorization: Bearer header, hit the v2 data endpoints under the https://api.prod.whoop.com base URL. The main ones (verify exact pluralization in the current docs):

• GET /v2/recovery — recoveries, paginated
• GET /v2/activity/sleep — sleeps
• GET /v2/activity/workout — workouts
• GET /v2/cycle — physiological cycles

# Sample: latest 10 sleeps
curl -X GET "https://api.prod.whoop.com/v2/activity/sleep?limit=10" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Results are paginated (follow the pagination token the response returns), and note that v2 payloads identify records with UUIDs, not integer IDs.

Step 6: Refresh tokens and (recommended) subscribe to webhooks

Refresh: when an access token expires, exchange the refresh token for a new one. Keep the offline scope so refresh keeps working (verify the exact refresh parameters — whether scope=offline must be re-sent — in the current docs).

curl -X POST "https://api.prod.whoop.com/oauth/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=refresh_token" \
  -d "refresh_token=THE_REFRESH_TOKEN" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "scope=offline"

Webhooks: instead of polling, register a webhook URL on your app. WHOOP POSTs when data changes. As of 2026 the v2 event types are recovery.updated, sleep.updated, and workout.updated (payloads reference records by UUID). Verify each POST before trusting it:

• WHOOP sends an X-WHOOP-Signature header plus a timestamp header.
• Recompute base64( HMAC-SHA256( timestamp_header + raw_request_body, client_secret ) ) and compare to the signature header. Drop the request on any mismatch.

Implement signature verification on day one — an unverified webhook endpoint is an open door.

Gotchas and production notes

• Membership is mandatory. No paid WHOOP membership means no data. Confirm your users own WHOOP before you build.
• 10-member cap until approval. You cannot exceed 10 connected members until your app clears WHOOP's App Approval flow. Budget review time before launch.
• Rate limits. Roughly 100 requests per minute and 10,000 requests per day per client (verify current limits). Responses carry X-RateLimit-* headers — read them and back off. Increases are available on request via WHOOP support.
• offline scope for refresh. Forget it and you get no refresh token, so your background sync dies when the first access token expires.
• v2 uses UUIDs. If you are porting from v1 integer IDs, update your storage and webhook routing.
• Keep the client secret server-side. It signs webhook verification and exchanges tokens; never ship it in a client app.

Treat rate limits, scope names, and endpoint pluralization as volatile — confirm them in the current WHOOP docs before you go to production. For a wider comparison of recovery and wearable providers, see wearable data APIs; to integrate a similar OAuth-based ring, see the Oura API guide.