Strava API integration guide for health and fitness apps

Open Wearables Team · June 1, 2026 · 4 min read

Key Takeaways

Integrating the Strava API directly requires building OAuth 2.0 authorization, token refresh logic, rate limit handling, and data normalization before you write a single line of product code.
Open Wearables abstracts the entire Strava API integration into three API calls: authorize, sync, and read.
Strava is activity-focused only. It does not provide sleep data, HRV, or continuous 24/7 metrics.
Open Wearables supports Strava alongside Garmin, Polar, Suunto, Whoop, Fitbit, and Ultrahuman through the same unified interface.
Strava setup requires only a free Strava account. There is no developer program approval process.
The stack is MIT-licensed, self-hosted, and has no per-user fees.
Workout data from Strava maps to 50+ activity types in canonical units (bpm, meters, Celsius, UTC).

What You Actually Have to Build When Integrating the Strava API Directly

If you decide to integrate the Strava API without an abstraction layer, the scope of work tends to surprise developers new to fitness API integrations.

The Strava API uses OAuth 2.0. That part is standard. But OAuth means you need a working redirect URI, a server-side token exchange flow, and persistent storage for access and refresh tokens. Strava access tokens expire after six hours, so you need a proactive or on-demand refresh mechanism. If a refresh fails at 3am, you need error handling and retry logic that does not silently drop a user's data.

Once you have tokens, you are hitting Strava's activity endpoints. The response shape is Strava's own schema: fields like moving_time, elapsed_time, total_elevation_gain, average_heartrate. If your app also connects to Garmin or Polar, every provider has a different schema. You end up writing a normalization layer that maps each provider's field names, units, and timestamp formats into your internal model.

Then there is rate limiting. Strava enforces per-15-minute and per-day request limits. You need queuing, backoff logic, and instrumentation to avoid hitting those limits in production.

What Open Wearables Does for You

Open Wearables is a self-hosted, open source layer that handles the full Strava API integration, plus other providers, through a single interface.

The authentication flow is standardized. You redirect your user to:

            GET /api/v1/oauth/strava/authorize?user_id={id}&redirect_uri={url}

Open Wearables handles the OAuth exchange with Strava, stores the tokens, and manages refresh automatically. Token refresh, rate limit handling, and retry logic live inside Open Wearables. You do not implement them.

All data is returned in canonical units regardless of source. Heart rate in bpm, distance in meters, timestamps in UTC. When you add a second provider later, your data model does not change.

The Strava Limitation You Need to Know Before You Build

Strava is an activity tracking platform. It is not a health platform.

Strava does not provide: sleep data, HRV, or continuous 24/7 metrics. If your app needs any of those, Strava alone is not sufficient. You would need to pair it with Whoop, Garmin, or Polar. Open Wearables supports all of them through the same API, so you can add providers incrementally.

What Strava does cover is workouts. If your use case is fitness activity tracking, training load analysis, or exercise history, Strava is a strong source.

Setting Up Strava in Open Wearables

Strava setup is straightforward compared to some other providers. You need a Strava account (free tier is sufficient) and a Strava API application created at strava.com/settings/api. There is no developer program approval process.

            git clone https://github.com/the-momentum/open-wearables.git
cd open-wearables
docker compose up -d

The API is available at http://localhost:8000. All requests use the X-Open-Wearables-API-Key header.

Authorizing a User

            GET /api/v1/oauth/strava/authorize?user_id={your_user_id}&redirect_uri={your_callback_url}

Open Wearables redirects the user to Strava's authorization page. After the user grants access, Strava redirects back through Open Wearables to your redirect_uri. The tokens are stored internally.

Syncing and Reading Data

            POST /api/v1/providers/strava/users/{user_id}/sync

To read workout data:

            GET /api/v1/users/{user_id}/events/workouts
GET /api/v1/users/{user_id}/timeseries

The response is the same schema whether the data came from Strava, Garmin, or any other connected provider.

See Related Articles

FAQ

Does Strava provide sleep data through the Strava API?

No. Strava is an activity tracking platform. It does not collect or expose sleep data, HRV, or continuous 24/7 health metrics.

Do I need a paid Strava account or developer program approval?

No. A free Strava account is sufficient. You create an API application at strava.com/settings/api to get your credentials.

How does Open Wearables handle Strava token refresh?

Strava access tokens expire after six hours. Open Wearables handles token refresh automatically using the stored refresh token. Your application does not need to implement refresh logic.

What activity types does Strava return through Open Wearables?

Open Wearables maps Strava activity data to a unified workout schema covering 50+ activity types including runs, rides, swims, hikes, and strength workouts in canonical units.

What happens if a user revokes Strava access?

Subsequent sync calls will fail with an authentication error. Your app should handle this by prompting the user to re-authorize via the OAuth endpoint.

Back to all posts