How to Integrate the Polar API (2026)

Polar's cloud API is AccessLink API v3, and it is one of the few self-serve wearable APIs: Polar's documentation says any registered Polar Flow user can create an API client at https://admin.polaraccesslink.com. This guide is built from that documentation, its swagger.yaml, and Polar's API license agreement, all read on October 17, 2026. It replaces an earlier version written only from Polar's example repository, which described AccessLink as pull-only with no published rate limits; Polar's own reference documents both webhooks and rate limits.

Still choosing a provider? That belongs to our wearable data APIs roundup; this page assumes the decision is made. Every page on this site that covers Polar is collected in the Polar API overview.

Access and approval#

Polar's getting-started list is short: create a Polar Flow account, log in at the admin site, create a client, get an authorization code for the user, exchange it for an access token, and register the user before you read anything. Users can change their consents at any time at https://account.polar.com.

Auth and scopes#

AccessLink uses OAuth 2.0 with the authorization-code flow only: Polar says "code" is the only response type supported.

GET https://flow.polar.com/oauth2/authorization
  ?response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=https://yourapp.example.com/oauth2_callback
  &state=RANDOM_ANTI_CSRF_STRING

• Scope. There is one: AccessLink uses the accesslink.read_all scope. If you leave scope out, the user is asked to authorize every scope linked to your client.
• Redirect URIs. redirect_uri must be identical to one registered for the client. You can register several and pick a default in the admin site; without the parameter, the only or default URL is used.
• State. Optional in Polar's table, but use it: Polar says it can be used to prevent CSRF attacks.
• The code is fragile. It expires in 10 minutes and must only be used once. If it is used more than once, Polar denies the request and deletes all tokens issued.

Exchange the code at the token endpoint, authenticating with HTTP Basic (your client ID and secret, base64-encoded):

curl -s -X POST "https://polarremote.com/v2/oauth2/token" \
  -u "YOUR_CLIENT_ID:YOUR_CLIENT_SECRET" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -H "Accept: application/json;charset=UTF-8" \
  -d "grant_type=authorization_code" \
  -d "code=AUTHORIZATION_CODE" \
  -d "redirect_uri=https://yourapp.example.com/oauth2_callback"

redirect_uri is required here only if you sent it to the authorization endpoint. The response holds access_token, token_type (bearer), expires_in and x_user_id, the Polar user ID used in later paths. Polar's documentation is not consistent on lifetime: the token response describes expires_in with an example of 31535999 seconds, about one year, while the section on making requests says access tokens "will not expire unless explicitly revoked by partners or users". Store expires_in and handle a 401 by sending the user through authorization again.

AccessLink then uses two kinds of authentication. Requests to /v3/users and its subresources use the user's bearer token; every other /v3/ request, such as /v3/notifications and the webhook endpoints, uses your client credentials as HTTP Basic. Mixing them up produces failures that look like bad tokens.

Register the user before reading anything#

Once a user has authorized you, Polar says you "must register the user before being able to access its data". POST your own identifier for them with the user's token:

curl -s -X POST "https://www.polaraccesslink.com/v3/users" \
  -H "Authorization: Bearer USER_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"member-id": "your-internal-user-id"}'

A 409 means the user is already registered to you or the member-id is a duplicate; a 403 means the user has not accepted all mandatory consents. GET /v3/users/{user-id} returns the user's basic information, and DELETE /v3/users/{user-id} de-registers the user, which Polar says "will revoke the access token authorized by user". Use it as your disconnect action.

Data: the non-transactional endpoints#

Polar has been replacing its transaction model with plain GET endpoints that take the user's token and need no transaction. Read windows differ by type, so design your sync around them:

curl -s -H "Authorization: Bearer USER_ACCESS_TOKEN" -H "Accept: application/json" \
  "https://www.polaraccesslink.com/v3/users/activities?from=2026-10-01&to=2026-10-16"

User endpoints answer 403 when the user has not accepted all mandatory consents, so treat that as a state to show the user, not a bug.

The deprecated transaction model#

Older integrations, including Polar's own example repository, use transactions: you POST to a per-user exercise-transactions, activity-transactions or physical-information-transactions path, GET the list of resource URLs, fetch each one, then PUT the transaction to commit. Committing is destructive: Polar's response for a commit reads "Transaction has been committed and data deleted." An exercise or activity transaction holds at most 50 items, and only data uploaded after the user registered with your client is available, within the last 28 or 30 days depending on which part of Polar's reference you read.

Polar's changelog deprecated the transactional endpoints for exercises and daily activity on August 18, 2025, and for physical info on January 13, 2026. New builds should use the non-transactional endpoints above. If you still run transactions, persist everything before you commit.

GET /v3/notifications, called with client credentials, still lists users with exercise or activity data waiting, each with a data-type and a URL; a 204 means nothing is available.

Webhooks#

AccessLink has webhooks, and they replace polling for most designs:

• One per client. Polar says a client application can only have one webhook registered. Create it with POST /v3/webhooks using client credentials, naming the event types and target URL.
• A ping first. On creation Polar sends a PING event to the URL, and the webhook is not created unless your endpoint answers 200 OK. Updating the URL with PATCH /v3/webhooks/{webhook-id} triggers a new ping.
• Save the secret at once. The create response carries a signature_secret_key that is "not available after create". Polar signs every payload with HMAC SHA-256 using that key and sends the result in a Polar-Webhook-Signature header, with the event type in Polar-Webhook-Event.
• Events. Payload schemas exist for EXERCISE, SLEEP, CONTINUOUS_HEART_RATE, SLEEP_WISE_CIRCADIAN_BEDTIME, SLEEP_WISE_ALERTNESS, ACTIVITY_SUMMARY and PHYSICAL_INFORMATION. Polar's exercise example carries event, user_id, entity_id, timestamp and a url to fetch.
• Failures. Delivery expects a 200 response. A webhook that has not delivered successfully for seven days is deactivated automatically; POST /v3/webhooks/activate turns it back on if your URL answers the ping, and POST /v3/webhooks/deactivate pauses it on purpose.

Rate limits#

Polar uses a dynamic limit that scales with your number of registered users and is recalculated daily:

Every response carries RateLimit-Usage, RateLimit-Limit and RateLimit-Reset, each holding two comma-separated values, short term first. Requests over the limit get 429, and requests that break the short-term limit still count toward the long-term one. Polar's license agreement also treats load testing without Polar's prior approval as interfering with its service, so do not benchmark against production.

What changed recently#

Gotchas and production notes#

• Register, then read. Authorization alone returns no data until you POST the user to /v3/users.
• No history before registration for exercises. Exercise endpoints return only data uploaded after the user registered with your client, and only from the last 30 days. Tell users that connecting Polar starts their exercise history rather than importing it.
• Short windows. The sleep, Nightly Recharge and SleepWise lists cover the last 28 days and exercises the last 30, so sync regularly or use the webhook.
• The code is single-use. Reusing an authorization code deletes all issued tokens.
• Consents can be withdrawn. A 403 after a working connection usually means the user changed consents at account.polar.com.
• Commit destroys, if you still use transactions. Persist and confirm the write before the PUT.

For webhook patterns in general, see what are webhooks; for the OAuth basics, what is OAuth for health data. Polar's single scope is far simpler than an Oura integration, which lists eight scopes users can toggle at consent. The rest of the cluster is at how to integrate a fitness or health API.