WHOOP API in 2026: Data Access, Permissions, and Limitations

WHOOP API in 2026: Data Access, Permissions, and Limitations

The WHOOP API allows applications to access a member’s sleep, recovery, strain and workout data with their permission. For teams building fitness, coaching or wellness products, the key questions are which measurements are available, what approval is required, and how the integration behaves once users connect.

WHOOP’s current developer API is V2, introduced in July 2025. Its November 2025 changelog confirmed that V1 webhooks were no longer being published. Developers maintaining older integrations need to account for those changes, particularly the move to UUID identifiers for sleep and workout records. WHOOP changelog

Getting started requires an application in the WHOOP Developer Dashboard. Developers register their application details, redirect URLs and requested permissions, then receive a client ID and client secret. The secret should remain on the backend. Developer setup

Development access is limited to 10 WHOOP members. Supporting more members requires application approval. WHOOP asks developers to test with at least one member, provide accurate contact information and a privacy policy, and follow its design guidelines. Approval requests go through the dashboard. The published instructions do not specify a guaranteed review time. App approval

The API separates access into six permission scopes:

Applications request the scopes their features need. Permission to retrieve sleep data does not automatically grant access to recovery or profile information. WHOOP scopes

Some records contain additional detail. Recovery can include blood oxygen percentage and skin temperature. Sleep records distinguish naps and include respiratory rate, sleep efficiency, consistency and components of sleep need. These fields can support more detailed experiences than displaying a single score. Recovery data, sleep data

The published standard API does not document endpoints for continuous raw heart-rate samples, ECG traces or journal entries. Features visible in the WHOOP consumer app therefore need to be checked individually against API coverage before becoming product requirements. API reference

Authorization uses OAuth 2.0. A member signs in to WHOOP and approves the requested permissions. The application then exchanges an authorization code for an access token. For ongoing synchronization, it must also request the offlinescope, which enables refresh tokens. WHOOP authentication

Refreshing a connection replaces both its access token and refresh token. Applications need to store the replacement pair and coordinate refresh attempts: two workers refreshing the same connection simultaneously can cause one request to fail because the first invalidates the previous token. Token refresh behavior

WHOOP’s data model also affects how measurements should appear in a product. It organizes activity around physiological cycles, which do not necessarily align with calendar days. The current cycle can have a start time without an end time. Applications displaying daily trends need to account for cycle boundaries and timezone offsets. Physiological cycles

Scores may also be unfinished or unavailable. Records distinguish SCORED, PENDING_SCORE and UNSCORABLE. A pending recovery or sleep score should remain pending in the interface; displaying zero would communicate something different. Existing records can subsequently change as data is processed or edited. Scoring states

For updates, WHOOP provides webhooks covering sleep, recovery and workouts. These contain event notifications and identifiers, rather than complete health records. The receiving application must then request the relevant data. New records arrive through updated events, and deletion events are also supported. Webhooks

Webhook coverage has limits. WHOOP currently documents no webhooks for Day Strain, cycles or body measurements, so those require API requests. Notifications can also be duplicated or missed. Integrations should validate signatures, handle duplicates and periodically reconcile their records. V2 recovery notifications identify the associated sleep by UUID, which matters when updating integrations that previously expected a cycle ID. Webhook limitations

Request volume becomes important as an application grows. WHOOP’s default limits are 100 requests per minute and 10,000 per day, per client. Exceeding a limit produces an HTTP 429 response. Developers can inspect the rate-limit headers and request higher limits through the dashboard. Rate limits

For example, requesting one endpoint every hour for 1,000 connected members produces 24,000 requests daily. That already exceeds the default allowance before historical imports, retries or additional data categories. An integration needs to budget for both ongoing updates and new-user onboarding.

Historical retrieval requires pagination. Collection responses return a next_token for fetching subsequent pages. Receiving the first page successfully does not establish that the application has retrieved the complete requested history. Pagination

Permissions also extend beyond authentication. WHOOP’s terms govern how applications use, share and retain data. They require member authorization and a clear privacy policy, prohibit selling or licensing API data to third parties, and place conditions on caching and permanent copies. API access is currently provided without an API usage charge, although WHOOP reserves the ability to introduce charges with notice. API terms

For teams bringing this data into a product, Terra provides the integration infrastructure around WHOOP. It manages user authentication and token refreshes, standardizes available records, and delivers updates to the application’s configured destination. This reduces the provider-specific authentication, parsing and synchronization work the team maintains. Terra’s data delivery

Through Terra’s WHOOP integration, applications can receive sleep, recovery, strain, workout and body-measurement data. Users connect through Terra’s authentication widget, while the application receives standardized payloads and can request available historical records. WHOOP through Terra

The setup requires your own WHOOP application credentials and the applicable WHOOP approval. Terra’s team supports the connection configuration, including the callback domain and certificate setup. Once configured, WHOOP becomes part of the same authentication and data-delivery flow your application uses for other supported wearable sources. Terra’s WHOOP setup guide

To add WHOOP to your product, start with Terra’s WHOOP integration and confirm the measurements your application needs.