Fitbit 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
- Cloud REST API (Fitbit Web API)
- OAuth 2.0 authorization code flow with PKCE
- Subscriptions API sends notifications; your backend then fetches data
- App types: Server, Client and Personal
- Data types
- Activity: steps, distance, active minutes, calories
- Heart rate, including intraday series where approved
- HRV, SpO2 and breathing rate
- Skin temperature variation
- Sleep stages and sleep logs
- ECG readings and irregular rhythm notifications where available
- Weight and nutrition logs
- Authorization requirements
- User consent through OAuth 2.0 for each requested scope
- Scopes per data category (for example activity, heartrate, sleep)
- Users can grant only some scopes or revoke access later
- Refresh token handling for long-running programs
- Developer approval & agreements
- Application registered in the Fitbit developer portal
- Intraday access request reviewed by Fitbit for third-party use
- Compliance with Fitbit and Google platform terms
- Terms and availability verified against current documentation at project start
- API limitations
- Per-user hourly rate limits on API requests
- Intraday time series need an approved request for Server and Client apps
- Subscription notifications carry no data; a follow-up fetch is required
- Data appears only after the device syncs to the user's account
- Account migration to Google accounts may affect users and terms
- Healthcare use cases
- Clinical and academic research studies
- Remote patient monitoring
- Sleep and activity programs
- Cardiac rhythm awareness programs
- Employer and payer wellness programs
Integration Methods and App Types
Fitbit offers three application types. Server and Client apps are used for third-party integrations that access other users' data; a Personal app can only access the data of the account that registered it. Personal apps can access that owner's intraday data, which makes them useful for prototypes but not for patient programs.
Authorization uses the OAuth 2.0 authorization code flow, with PKCE recommended. Your backend stores access and refresh tokens securely, refreshes them before expiry, and handles revoked consent. Data is read with REST calls scoped to the categories the user approved.
- Authorization code flow with PKCE
- Encrypted token storage with automatic refresh
- Subscription endpoint with verification and signature checks
- Queued fetches that respect per-user limits
Available Data Types
The Web API exposes daily summaries and time series for activity, heart rate, sleep, body measurements and nutrition, as well as health metrics such as HRV, SpO2, breathing rate and skin temperature variation. ECG readings and irregular rhythm notification results are available through dedicated endpoints where the feature is supported for the user's device and region.
Intraday time series, such as heart rate at second or minute resolution and minute-level steps, require an approved request to Fitbit for Server and Client apps. We include that request in the project plan and design the data model so it works with daily summaries if intraday access is not granted.
Rate Limits and Other Limitations
Fitbit applies per-user hourly rate limits. Large backfills and high-frequency polling quickly hit these limits, so we use the Subscriptions API to learn when new data exists and fetch only what changed. Subscription notifications identify the user and data category but do not contain the data itself.
Data reaches Fitbit's servers only after the device syncs, typically through the Fitbit mobile app. Gaps often reflect sync behaviour rather than missing measurements, and we surface last-sync times so care teams can tell the difference.
Per-user limits
Requests are capped per user per hour; pipelines must queue and pace calls.
Sync dependency
New data appears only after the device syncs with the user's account.
Platform changes
Google account migration and policy updates may change access over time.
Healthcare Use Cases
Fitbit integrations are common in clinical research, remote patient monitoring, sleep programs, cardiac rhythm awareness and wellness programs. Server-side access means participants do not need to install a separate study app, though they still need the Fitbit app to sync.
Consumer wearable data is not a substitute for clinical-grade measurement unless validated for the intended use. When Fitbit data feeds clinical workflows, we map it with clear provenance through EHR integration so clinicians can see its source.
Frequently asked questions
Do we need a mobile app to integrate Fitbit?
Not for data access. The Fitbit Web API is a cloud API accessed from your backend after users authorize through OAuth. Users still need the Fitbit app for their device to sync.
Can we get minute-level or second-level heart rate data?
Intraday data is available to Server and Client apps only after an approved request to Fitbit. Personal apps can access the owner's own intraday data. Approval is not guaranteed.
What rate limits apply?
Fitbit applies per-user hourly rate limits. We use subscriptions and paced fetching to stay within them. Current limits are confirmed against Fitbit documentation at project start.
How does the move to Google accounts affect integrations?
Fitbit is owned by Google and accounts have been moving to Google accounts. API terms and products may change, so we check the current status before committing to an architecture.
Can we receive data in real time?
Not directly. Subscriptions notify your endpoint when new data has synced, and your backend then fetches it. Freshness depends on how often the device syncs.