How to Integrate Strava Without Building OAuth From Scratch

Key Takeaways

• Building a production Strava integration means writing OAuth 2.0, token refresh, webhook handling, rate limit logic and a data normalization layer before shipping any product feature
• Each of these pieces is non-trivial, and together they represent weeks of engineering work that has nothing to do with your actual product
• The challenge multiplies when you add more providers: every wearable API has a different OAuth flavor, different token lifecycle and different data schema
• Open Wearables is an open-source, self-hosted platform that handles this entire infrastructure layer for Strava and eight other providers simultaneously
• MIT licensed, $0 per user, deployable in under an hour via Docker Compose

Introduction

Adding Strava to a health or fitness app sounds like a two-day job. In practice, it often turns into two weeks once you account for everything production requires.

The OAuth flow itself is straightforward enough. Redirect the user, handle the callback, exchange the code, store the tokens. But that is only the beginning. Strava access tokens expire after six hours, which means every API call needs to check token expiry first and refresh proactively if needed. Rate limits are enforced at 100 requests per 15-minute window and 1000 per day per athlete, which means you need per-user tracking in your backend infrastructure, not a global counter. Webhooks require a publicly reachable validated HTTPS endpoint before Strava will send you anything. And when you add the second provider, you repeat all of this from scratch with different conventions.

This post covers what it actually takes to build a Strava integration that works reliably in production, and what a simpler path looks like for teams who need multiple providers without the infrastructure overhead.

The OAuth Problem Is Bigger Than You Think

OAuth 2.0 with Strava follows the standard authorization code flow. But the operational burden starts immediately after the initial exchange. Strava issues access tokens with a six-hour expiry, which is significantly shorter than most providers. This means you cannot fetch a token at connection time and reuse it. You need a refresh mechanism woven into your data layer that checks expiry before every API call.

In a small codebase, this might be a single helper function. In a production system with multiple services, background jobs and async workers all potentially making Strava API calls, token management becomes a cross-cutting concern. Every component that touches the Strava API needs access to up-to-date tokens for each user. The tokens need to be stored persistently, refreshed atomically so two concurrent processes do not both try to refresh the same token simultaneously, and cleaned up properly when a user deauthorizes your app.

Deauthorization itself is an edge case that is easy to miss in development and critical in production. When a user removes your app from their Strava connected applications, their refresh token is invalidated. Your next API call returns a 401 with a specific error indicating token revocation, not a generic auth failure. Your code needs to detect this, mark the connection as disconnected in your database, and surface a re-authentication prompt to the user rather than silently failing.

Rate Limits Are a System Design Problem

The 100 requests per 15 minutes and 1000 per day limits sound generous in development. In production, they shape how you architect your entire data pipeline.

Consider a user who has been on Strava for three years and runs four days a week. That is roughly 600 activities. If you want to backfill their history when they first connect, and you fetch activity summaries plus GPS and heart rate streams for each one, you are looking at well over 1000 API calls for a single user. That exceeds the daily limit before you have even touched a second user. You need a backfill strategy that spreads historical sync over multiple days, prioritizes recent data, and handles interruption and resumption gracefully.

For ongoing sync, the answer is webhooks rather than polling. Polling on a fixed schedule burns through rate limits regardless of whether there is new data. Webhooks notify you when something actually happens. But webhooks introduce their own complexity: a publicly reachable HTTPS endpoint that responds to Strava's validation challenge within seconds, asynchronous processing so the webhook handler returns 200 immediately while actual data fetching happens in a queue, idempotent processing so duplicate deliveries do not create duplicate records, and dead-letter handling for events that fail processing.

None of this is rocket science, but it is real engineering work. For a team focused on building a coaching or wellness product, it is work that delays the features users actually care about.

The Multi-Provider Problem

Strava is rarely the only provider a health app needs. Users who run on Strava also sleep with an Oura Ring, train with a Garmin watch, and track recovery with Whoop. A compelling product needs data from wherever the user actually generates it.

Each provider has its own OAuth flavor, token lifecycle, rate limits and data schema. Garmin uses OAuth 1.0a and push-based delivery, not OAuth 2.0 and polling. Apple Health requires an iOS SDK rather than a server-side API. Whoop has rotating refresh tokens that must be stored after every exchange. The implementation patterns are different enough that there is very little code reuse between providers.

The result is that adding each new provider takes a substantial engineering investment, and the infrastructure complexity grows non-linearly. By the time you have three or four providers integrated, you have a significant maintenance surface: token refresh for multiple providers, webhook handlers for multiple event formats, normalization logic mapping each provider's schema to yours, and monitoring to detect when any of these stops working.

Open Wearables

Open Wearables is an open-source platform that handles the integration layer for Strava and eight other providers: Garmin, Polar, Whoop, Oura, Apple Health, Samsung Health, Google Health Connect and Suunto.

Instead of building OAuth, token refresh, rate limit tracking and webhook handling per provider, you deploy Open Wearables once and get a unified API for all of them. Users connect their wearables through built-in OAuth flows. Tokens are managed server-side. Webhook events are processed automatically. Your application queries a single normalized endpoint and receives activity data in a consistent schema regardless of which provider it came from.

The platform runs on your infrastructure. Data never leaves your servers. The MIT license means there are no per-user fees, no vendor lock-in and no pricing changes that can affect your unit economics as you scale. Infrastructure cost for a startup-scale deployment is typically $200 to $500 per month regardless of user count.

FAQ

Is it faster to build the Strava integration myself or use Open Wearables?

For a single provider, building directly is viable. For multi-provider apps, Open Wearables removes weeks of infrastructure work and eliminates the ongoing maintenance overhead of keeping multiple integrations up to date as provider APIs change.

Does Open Wearables support all Strava data types?

Open Wearables syncs activities including GPS traces, heart rate, power, pace, elevation and calories. See the Strava integration page for the full data schema.

Can I run Open Wearables on my own servers?

Yes. Self-hosted via Docker Compose or one-click Railway deployment. Your data never leaves your infrastructure.

What if I only need Strava for now?

You can configure Open Wearables with only the providers you need. Enable Strava today and add Garmin or Whoop later without any architectural changes to your product.

Is Open Wearables production-ready?

The Strava integration is production-ready and used by several health tech companies. Open Wearables is at v0.3.0-alpha with a stable data layer. Check the GitHub repository for current status and release notes.

Strava Integration

View the full Strava integration documentation on Open Wearables.

See Related Articles

Strava API Developer Guide: Activities, Heart Rate and GPS Data

Polar API: Training, HRV and Nightly Recharge Data

Garmin Connect API: Developer Guide for Activities and Health Metrics