Skip to main content
Question

Standard Tier — Confirming full access to core activity/athlete/webhook endpoints

  • September 17, 2026
  • 5 replies
  • 124 views

Forum|alt.badge.img+1

Hi everyone,

I'm about to start building a fitness application on Strava API v3 under the Standard Tier developer program. My app lets individual users authenticate via OAuth 2.0 and sync their personal activity records into my app's database.

Before I start development, I wanted to confirm that the following endpoints are fully available (read + write where applicable) under Standard Tier:

  • Activities: GET /athlete/activities, GET /activities/{id}, POST /activities
  • Streams: GET /activities/{id}/streams (GPS, heart rate, power)
  • Webhooks: POST /push_subscriptions (for real-time sync instead of polling)
  • Athlete Data: GET /athlete, GET /athletes/{id}/stats

I've already checked the changelog and understand that the Club endpoints (Activities/Members/Admins) were removed and GET /segments/explore now requires Extended Access Tier — so I'm not asking about those.

Two questions for the community:

  1. Can anyone confirm these four groups are unaffected by the recent Standard Tier changes and still work as documented?
  2. Are there any other endpoints worth knowing about for a personal activity-sync use case like mine (e.g. gear, routes, segments) that I should plan for early, even if I don't need them at launch?

Thanks in advance — happy to share what I learn back here once I've built and tested it.

5 replies

Jan_Mantau
Forum|alt.badge.img+26
  • Hub Powerhouse
  • September 17, 2026

These endpoints work and you wouldn’t necessarily need other endpoints if you only want to load activities.

If you plan to connect more than the default 10 Strava users, be aware of the retention rule of maximum 7 days for data downloaded from the Strava API.


Forum|alt.badge.img+1
  • Author
  • Hub Rookie
  • September 18, 2026

Follow-up on the 7-day retention rule: does it apply only to raw API responses, or also to derived values I extract and store myself (e.g. distance + date per activity), and would rolling those into monthly aggregate totals (then discarding per-activity rows) be a compliant way to keep multi-year leaderboard history?


Jan_Mantau
Forum|alt.badge.img+26
  • Hub Powerhouse
  • September 18, 2026

Distance and date are part of the API response. Aggregated totals aren’t explicitely mentioned in the retention rules, so technically it would be allowed but Strava is free to reject it anyway since they don’t need or communicate reasons for rejections.


Forum|alt.badge.img+1
  • Author
  • Hub Rookie
  • September 19, 2026

Thanks for the earlier clarification on raw fields vs. aggregates.

Practical question this raises: if I'm running a competition (e.g., a team leaderboard) over a full month or longer, and I can't retain raw activity data (distance, date, etc.) beyond 7 days, how is a month-long competition supposed to function at all?

My current plan to work around this:

  • Store only a strava_activity_id reference + my own computed points value per activity (not the raw distance/date fields)
  • For any live view of a member's activity history, fetch it fresh from the API each time, rather than storing it

Is this "store points, not raw fields" approach the intended way developers are expected to build month-long competitions under this policy? Or is there a supported/documented pattern for competitions spanning longer than 7 days that I'm missing — e.g., a specific endpoint or permission tier meant for this exact use case?

Trying to understand if I'm working around a limitation correctly, or if there's a more direct way this is meant to be handled.


Jan_Mantau
Forum|alt.badge.img+26
  • Hub Powerhouse
  • September 19, 2026

Apps aren’t supposed to provide leaderboards because that threatens Strava’s income model where most leaderboards are behind paywalls. There may be exceptions but Strava never really made public under which circumstances they grant one.