Strava API FAQ

 Clear answers to the questions that come up most, so you can spend more time building. 

New to the Strava API? Start by creating your API application. Once you're set up, this FAQ covers the questions developers run into most.

Q1: What's the fastest way to explore the API before writing any code?

Use the Swagger Playground. It lets you make live API calls and inspect real responses without writing a single line of code, which is a good way to validate what data is actually available before building against it.

To get started, go to strava.com/settings/api and temporarily set your "Authorization Callback Domain" to developers.strava.com. Then visit the Playground, click the green "Authorize" button, and enter your Client ID and Client Secret. You'll be able to call any endpoint interactively and see exactly what the API returns for your own account.

⚠️ Before you go live: remember to reset your "Authorization Callback Domain" back to localhost (or your real domain) when you're done exploring.

Q2: How do I move from the 1 athlete limit to being able to share my app with other users?

By default, all new API applications are capped at 1 connected athlete (you, the developer). To connect additional athletes, submit your app for review here.

When submitting, include:

• What your app does and the problem it solves for athletes
• Your expected user scale (even a rough estimate helps)
• Confirmation that your app complies with the API Agreement and Brand Guidelines

Other things to note:

• The clearer your submission, the smoother the review process.
• If users trying to connect to your app are receiving a 403 "Limit of connected athletes exceeded" error while your review is in progress, this is expected and will be resolved when, and if, your app is approved.

Q3: How long does the review take?

App reviews typically take 7-10 business days. Thorough, detailed submissions move through the process most efficiently.

A few things that help move it along:

• A clear description of your app's use case: what it does, who it's for, and how it uses Strava data specifically
• Screenshots showing every place Strava data appears in your app: this removes ambiguity for the reviewer and demonstrates a working integration
• Your expected user scale: even a rough estimate helps provide clarity
• Confirmation that your app complies with the API Agreement and Brand Guidelines
• If your application is leveraging AI, please provide explicit information around how this works in relation to data obtained from the Strava API (note: please see our API Agreement for what is allowed)

If you haven't heard back after 10 business days, feel free to follow up at developers@strava.com with your submission date and Client ID.

Q4: I'm just accessing my own data. Do I need to go through the full review process?

If you're only connecting your own Strava account to your own script or tool, you're good to go. Get your access token directly from strava.com/settings/api and start making requests right away.

The review process is required only when you want other athletes to connect to your application. For personal scripts, single-user dashboards, or background tools that touch only your own data, you're ready to go.

Keep in mind that access tokens expire every 6 hours, so you'll need to handle the refresh token flow for anything that runs unattended.

Q5: How do OAuth scopes work, and which should I request?

Scopes define what data your app can access on behalf of an athlete. They are requested in the authorization URL, not configured in the dashboard. 

Available scopes:

Only request what your app genuinely needs. Athletes see exactly what permissions you're asking for, and requesting more than necessary lowers authorization conversion and can slow down app review.

💡 Best practice: Always verify which scopes were approved when an athlete connects to your app.

Q6: How do I handle token refresh and user deauthorization at scale?

Token refresh: Access tokens expire after 6 hours. Store the refresh token securely for every connected athlete and use it to obtain a new access token on demand. Refresh when a request returns a 401. Never store only the access token.

Refresh tokens can expire at any time. Every time you retrieve a new access token, you will receive an updated refresh token. Once a new refresh token has been issued, the previous one will no longer work. Always store the latest refresh token returned and never reuse an old one.

For multi-user apps, manage tokens per athlete and handle refresh failures with a re-auth prompt rather than a silent failure.

Deauthorization: Properly implementing deauthorization is one of the most important things you can do as a Strava API developer. When athletes disconnect your app or stop using it, removing them via the deauthorization endpoint keeps your user count accurate and your integration healthy.

💡 Best practice: Apps that actively manage deauthorization maintain a lower connected athlete count, which directly impacts your eligibility for athlete capacity increases. It's one of the highest-impact things you can do as a Strava API developer.

Per the API terms, you must use webhooks to detect when an athlete revokes access to your app. When you receive a deauthorization webhook event, immediately delete that athlete's tokens and their respective data from your database.

If an athlete is blocked from re-pairing, have them manually disconnect from strava.com/settings/apps and re-authorize.

There is currently no API endpoint to list or audit all active token holders for your application, so token lifecycle management is your responsibility.

Q7: What are the rate limits and how do I avoid hitting them?

Rate limits apply per application, not per athlete, and every API call counts against both the 15-minute and daily windows simultaneously.

Note the headers on every response:

X-RateLimit-Limit: 200,2000

X-RateLimit-Usage: 32,198

The first value in each pair is the 15-minute window; the second is the daily. Build monitoring around these so you always know where you stand.

Common causes of accidental exhaustion:

• Background sync jobs that burst at midnight or on a schedule without accounting for total request volume
• Retry loops without backoff
• Fetching full activity data for every athlete on startup instead of using webhooks to sync incrementally
• Fetching an athlete’s entire activity history – we recommend you only sync at maximum the last 30 days of activity data. If users want to sync their entire history with your app, they can request a data export. 

If you hit the limit, the 15-minute window resets at the next 15-minute boundary and the daily resets at midnight UTC.

If your use case consistently requires higher limits, and you’ve optimized your usage (i.e., webhooks) email developers@strava.com with your Client ID, current vs. needed limits, and a clear explanation of your usage pattern.

Q8: How do I set up webhooks, and why do they fail verification?

Webhooks push events (new activity, select activity updates, activity deletion, deauthorizations) to your endpoint in near-real-time. Implementing webhooks is one of the most effective ways to avoid accidentally exhausting your rate limit. Instead of polling the API repeatedly to check for new data, webhooks notify your app only when something changes. Full setup instructions: developers.strava.com/docs/webhooks.

Q9: How do I create an activity via the API?

There are two ways to create an activity via the Strava API, and the right choice depends on how much data you want to associate with it.

The createUpload endpoint is the recommended path for apps that record workouts. By uploading a FIT, GPX, or TCX file, you get the fullest and most accurate representation of an activity on Strava, including GPS traces, heart rate, power, cadence, and more. Upload documentation can be found here. 

The createActivity endpoint is best suited for manual or simple activity creation where a file isn't available. It supports basic fields like name, type, start date, and duration, but has some limitations worth knowing upfront. 

Both endpoints require the activity:write scope. Make sure you are requesting this during authorization before attempting to create activities on behalf of an athlete.

Q10: I really think you should expose something via the API, how can I provide feedback?

We actively monitor developer feedback to help inform what gets prioritized. If there's a feature you see on Strava that you think should be exposed via the API, we want to hear about it. Submit a feature request here. 

Q11: Where do I go for help, and what's the right channel for each type of issue?

⚠️ Before you go: never share your Client Secret, access tokens, refresh tokens, or authorization codes in any public forum. If you've accidentally exposed any of these, regenerate them immediately from your API settings page.