01-03-2023 03:40 AM
Hi, I'm trying to build a small app for my company's Strava club to track weekly "winners" similar to how the club page shows "Distance / Total Running Time / Climbing" leaderboard entries and ran into a few issues in the process that I'd like to raise as well as a suggestion on how to mitigate why I think you built the API the way you did.
My goal is to track the 1st/2nd/3rd place for each week and accumulate "medals" for people over the course of the year. Additionally, I'd like to store and keep certain things updated such as "Longest Run This Year" or "Most Elevation In A Run This Year" and post when someone sets a new record. However, I ran into a few issues with the Clubs API and would like to see if there's a different way to accomplish this OR if I can make suggestions instead:
I understand for privacy reasons, you may not want to return the exact activity ID or athlete ID that you use elsewhere, but perhaps as a workaround you generate a per-club GUID? I don't need to know the athlete's global Strava ID, I just need to know in a consistent and deterministic manner which "Joe B." posted a run so I can accurately track leaderboards. If there's a different API endpoint I should be calling instead, or something I can use to gather additional details about the activities and athletes, that would be great as well.
My only other thought is to instead just have all of the folks from my company's running club individually authorize my app, at which point I can scrape their activities as individuals and generate my own leaderboard from the people who authorized the app, but then that completely defeats the purpose of having a Club, as we won't be relying on that at all.
03-18-2023 02:09 PM
Basically having the exact same requirements ... i found out there is a parameter "after" accepting a unix timestamp which i could not find in the docs (at least not for the club activities endpoint), but i seems to work (just some quick tests). Might help at least avoiding the cron job.
03-14-2023 02:36 PM
@Winterspite and @dblock, thank you for your posts. We are always looking for ways to improve the API and have made a note of this internally.
01-03-2023 05:56 AM
You are right not to rely on club activities. They are only useful as a way to display something minimal. The additional problem is that even when the user connects their account, clubs return an anonymous version of the activity. This causes us to have to de-dup activities by comparing a bunch of fields. I think your GUID idea for an athlete ID is interesting, but it would effectively become a second, public ID for a user in the club, and for public club information would make it one little step easier to de-anonymize that "Joe B.".
I think Strava removed all this information to prevent people from building competitive club apps, not to really ensure their privacy. Which is a sad strategy. If someone at Strava is reading I'd return full activities in the club feed if the user authorized my app, and, if the argument is really not a privacy one, only for Premium users.
Welcome to the Community - here is your guide to help you get started!