Skip to main content
Question

Clarification on API Policy §6.2 - retaining an athlete's own activity data for historical comparison

  • September 9, 2026
  • 2 replies
  • 28 views

Forum|alt.badge.img+1

I'm building a read-only Strava application (Standard Tier, activity:read_all only, no write scope). It groups an athlete's own activities by distance, every half marathon, every century ride, and shows them side by side so the athlete can see how their performance has changed over time.

That comparison is only meaningful across months and years, so the application caches each authenticated athlete's own activity data locally. Querying live per interaction isn't feasible within the rate limits.

API Policy 6.2 states that Strava Data may not be retained in cache longer than seven days, and 6.4 limits retention to what is necessary for the original purpose. I can't find a carve-out for retaining an athlete's own data for the life of their account with a third-party application.

Two questions:

  1. May an application retain an authenticated athlete's own activity data for as long as that athlete remains an active user of the application, where the sole purpose is presenting that athlete's own history back to them? If so, is there a technical arrangement you'd expect, for example a deletion window on deauthorization? My application deletes immediately on the deauthorization webhook.
  2. The application can generate an image summarizing an athlete's own comparison, which the athlete may choose to post publicly. It contains only that athlete's own data, and only that athlete can create it. Is that compatible with the requirement that Strava Data be displayed only to the user it belongs to?

I would rather build to the correct interpretation now than discover it at app review.

2 replies

Jan_Mantau
Forum|alt.badge.img+26
  • Hub Powerhouse
  • September 9, 2026
  1. The athletes own data is the same as Strava data if it comes from the API, therefore the 7 days retention must be applied. The deletion after deauthorization is mentioned in 6.3 with 48 h maximum.
  2. If your app actively helps the user to make Strava data public the review team probably won’t like that.

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

@Jan_Mantau thank you for such a quick reply! I appreciate it. 

 

Follow-up to the retention question you answered earlier: understood that an athlete's own performance data retrieved via the API is subject to the 7-day cache limit (6.2) with no owner-display exception.

Narrower question: would it be compliant to retain, indefinitely, a minimal index containing only an activity's Strava ID, activity type, and date - with no performance data (no distance, pace, splits, HR, power, or name) - used purely to identify which of an athlete's activities to re-fetch live from the API on demand? The performance data itself would never be cached beyond the 7-day window; it would be fetched fresh from the API each time the athlete requests to view it, computed in memory, and discarded.

In short: is a bare pointer/index (activity ID + type + date only, no substantive data) treated the same as the underlying Strava Data it references, or is that distinction meaningful for the 7-day retention limit?