Polar API: at a glance
Summary based on publicly available vendor documentation. Vendor terms, endpoints and limits change; we verify them against current documentation at the start of every project.
- Integration methods
- Polar AccessLink API v3 (cloud REST, OAuth 2.0)
- Webhooks for events such as EXERCISE and SLEEP
- Polar BLE SDK (open source) for direct device streaming
- Exercise files in TCX, FIT and GPX formats
- Data types
- Training sessions with heart rate samples
- Daily activity and physical information
- Sleep and Nightly Recharge
- Continuous heart rate and cardio load
- ECG, accelerometer and HR/RR streams via BLE SDK (device dependent)
- Authorization requirements
- User authorizes your client via Polar OAuth 2.0
- App must register the user to the client after OAuth
- BLE SDK requires Bluetooth permissions on the phone
- Users can deregister or revoke access
- Developer approval & agreements
- Registered AccessLink client and acceptance of Polar developer terms
- Commercial use subject to Polar's terms and possible agreement
- BLE SDK license terms apply to distribution
- Requirements checked against current Polar documentation
- API limitations
- Transactional model requires create, list, get and commit steps
- Committed transaction data is removed from the queue
- Data available only after the device syncs to Polar Flow
- BLE streaming requires the app to stay connected to the sensor
- Endpoints and rate limits change; verified at project start
- Healthcare use cases
- Clinical and sports science research
- Cardiac rehabilitation activity monitoring
- HRV and recovery studies
- Remote monitoring with chest strap ECG
Supported integration methods
Most cloud integrations use AccessLink API v3. After the user completes OAuth 2.0, your application must register that user to your client before data becomes available. Webhooks can notify your service of new exercises, sleep and other events.
For live data, the Polar BLE SDK connects directly to supported Polar devices from a mobile app. This bypasses the cloud entirely, which helps research protocols that need raw signals. Our wearable API integration approach covers both paths with a shared data model.
Transactional endpoints
Historically, exercises, daily activity and physical info use a transaction model: create a transaction, list items, get each item, then commit. Uncommitted data stays available; committed data is removed from the transaction queue, so commits must happen only after data is safely stored.
Non-transactional endpoints
Newer endpoints provide some data directly, such as exercises, sleep, Nightly Recharge, continuous heart rate and cardio load. We confirm which endpoints are current for each data type at project start.
Polar BLE SDK
An open-source SDK on GitHub for streaming heart rate, RR intervals, ECG and accelerometer data from devices such as the H10 chest strap and Verity Sense, depending on device capabilities.
Data types
AccessLink exposes training sessions with heart rate samples, exercise files in TCX, FIT and GPX formats, daily activity, sleep, Nightly Recharge, continuous heart rate, cardio load and physical information such as weight and height.
Through the BLE SDK, the H10 can stream ECG, accelerometer and heart rate with RR intervals, while optical sensors like Verity Sense provide PPG-based data. Available streams and sample rates vary by device and firmware.
Recovery metrics such as Nightly Recharge and cardio load are calculated by Polar using its own methods. We store them as vendor-derived values, separate from raw measurements like heart rate samples, so analysts and clinicians can see which numbers come directly from a sensor and which are proprietary scores that may change between firmware or algorithm versions.
API limitations to plan around
The transaction model is easy to get wrong: committing before data is persisted can lose data permanently from the queue. We implement idempotent fetches and commit only after successful storage.
For research studies that stream data through the BLE SDK, the phone app becomes part of the measurement system. Connection drops, operating system background limits and battery levels all affect data completeness, so we log connection state alongside the signal and give study teams clear completeness reports.
- Cloud data appears only after the user syncs with Polar Flow
- BLE streaming depends on an active phone connection and app lifecycle
- Rate limits and endpoint versions change and are verified at project start
- Mixed transactional and non-transactional endpoints need clear ownership in code
Healthcare use cases
Polar devices are widely used in research for heart rate and HRV measurement, and in cardiac rehabilitation programs that track exercise sessions. Chest strap ECG and RR data can support studies of arrhythmia screening workflows or autonomic function, subject to protocol and validation.
Data can feed remote patient monitoring dashboards or research data stores, and can be compared alongside other sources such as Garmin Health API data. Consumer device data is not a substitute for clinical-grade measurement without validation for the intended use.
Frequently asked questions
What is Polar AccessLink?
AccessLink is Polar's cloud REST API, currently v3, using OAuth 2.0. It provides training, activity, sleep and recovery data that users have synced to Polar Flow.
Why do we need to register users after OAuth?
AccessLink requires your application to register each authorized user to your client before their data is available. Skipping this step is a common cause of empty responses.
What happens if we commit a transaction too early?
Committed data is removed from the transaction queue. If it was not stored first, it cannot be fetched again through that transaction, so commits should follow successful persistence.
Can we stream ECG from a Polar H10?
The open-source Polar BLE SDK supports streaming ECG, accelerometer and heart rate with RR intervals from the H10, from a mobile app connected over Bluetooth.
Is Polar data suitable for clinical decisions?
Polar devices are consumer and sports products. Their data can support research and monitoring, but it should be validated for the intended clinical use before informing decisions.