--- title: "How to Integrate Strava Without Building OAuth From Scratch" description: "What a production Strava integration really requires, and how Open Wearables eliminates the OAuth, token refresh, webhook and rate limit infrastructure work." canonical_url: "https://openwearables.io/blog/how-to-integrate-strava-without-building-oauth-from-scratch" --- # How to integrate Strava without building OAuth from scratch [All posts](https://openwearables.io/blog) [Strava](https://openwearables.io/blog/category/strava) Open Wearables Team · May 4, 2026 · 5 min read ## 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. For a full breakdown of how the Strava API changed in 2026, including the new developer tiers, retired endpoints, and upcoming breaking changes, see the [Strava API 2026 developer guide](https://openwearables.io/blog/strava-api-developer-guide-activities-heart-rate-gps-data). 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 connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Strava integration View the full [Strava integration documentation](https://openwearables.io/integrations/strava) on Open Wearables. ## See related articles [Strava API Developer Guide: Activities, Heart Rate and GPS Data](https://openwearables.io/blog/strava-api-developer-guide-activities-heart-rate-gps-data) [Polar API: Training, HRV and Nightly Recharge Data](https://openwearables.io/blog/polar-api-training-hrv-nightly-recharge-data) [Garmin Connect API: Developer Guide for Activities and Health Metrics](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) ## Keep reading Strava · May 6, 2026 · 11 min read ### Strava API 2026: developer guide to activities, heart rate and GPS data A practical guide to connecting Strava's API in production: OAuth token refresh, rate limits, webhooks, and how to normalize activity data across multiple providers. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book)