Hello everyone,
I’m looking for some clarification before submitting another Standard Tier request for our application. I’d like to make sure that our use of the Strava API is aligned with the current API Policy before resubmitting.
ONAtrail is a specialized trail running performance web platform designed to support athletes before, during, and after their races.
Through the Strava API, athletes can connect their own activity history to access trail-specific insights within their personal ONAtrail account. These include elevation-based performance metrics, climbing and descending analysis, personalized athlete performance profiles, and detailed post-race analysis.
The platform also provides trail race preparation tools, including pacing assistance based on course characteristics and historical race performance data.
Strava data is used for the authenticated athlete within their own account. We do not display one athlete's Strava data to another athlete.
We have submitted four Standard Tier requests so far, improving the application and the information provided each time. The latest request was submitted after our website had officially launched and the product and support website were publicly available.
Rather than submitting another request without understanding the relevant requirements, I would really appreciate clarification on a few points:
1. Personalized analytics
Our core use case is to transform an athlete's own Strava activity data into trail-specific metrics and analyses that are displayed only to that same athlete.
For example:
-
climbing and descending performance;
-
elevation-based performance metrics;
-
personalized performance profiles;
-
post-race analysis.
Would this type of individualized analysis of an athlete's own Strava data be considered an allowed use under the current API Policy, particularly in light of Section 5.4?
2. Longitudinal use of an athlete's own data
To provide a meaningful history of an athlete's performance, our application needs to work with previously authorized activity history rather than only the most recent activities.
How should developers interpret Sections 6.2 and 6.4 in this situation?
More specifically, if the core purpose of the application is to provide an athlete with a longitudinal view of their own performance, can retaining the data necessary to provide that personal history be considered necessary for the purpose for which it was originally obtained?
Or does Section 6.2 effectively limit the underlying Strava data to a seven-day retention period, even when it is used only to provide historical functionality to the same athlete?
3. Derived metrics and historical insights
Our platform generates metrics and analyses from an athlete's Strava activities, such as climbing performance, elevation-based metrics and historical performance indicators.
If the underlying Strava activity data is subject to retention restrictions, are derived metrics or historical insights generated from that data subject to the same restrictions?
For example, would it be permissible to retain a historical performance metric generated from an athlete's own Strava activity, or does Section 5.4 also restrict the retention and use of those derived metrics?
4. Combining Strava data with data collected directly by the application
Some ONAtrail functionality may combine Strava activity data with information provided directly by the athlete within ONAtrail, such as race information or questionnaire responses.
Does Section 5.4 prohibit this type of combination when the resulting analysis is still private to the same athlete and is not used for aggregation, comparison between users, or product improvement?
5. Standard Tier review
Finally, regarding the review itself: for an application with 10 authenticated athletes that is preparing to onboard more users, what are the main factors considered when reviewing a Standard Tier request?
Is meaningful API usage from the existing users expected before an increase in athlete capacity can be approved, or can a request be approved based on the product, use case, compliance, existing users, and planned rollout?
We are not looking to bypass the review process. We simply want to make sure we understand the current policy correctly and that our implementation is compliant before submitting another request.
Any guidance from someone familiar with the API review process would be greatly appreciated.
Thank you!