Club API Feedback and Improvements

[Winterspite]

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:

• Club API doesn't return a timestamp for activities when you call getClubActivitiesById. That's fine, I can work around that by just calling via cron job every 15 minutes and can roughly figure out when new activities are added. Ideally I could subscribe to a webhook for notification on new runs, but that one isn't really a big deal. I will note that the API doesn't explicitly say if the results are in any kind of a sorted order (although they appear to be from my testing).
• Club API doesn't return a unique activity ID when you call getClubActivitiesById. This one isn't great. I can try to generate my own unique hash by grabbing hopefully deterministic fields like moving time, distance, etc. - but I also know that people can go edit their runs to trim them, so that might change and break my way of knowing "have I seen this run / added it to my tracker yet or not?"
• Club API doesn't return a unique athlete ID when you call getClubActivitiesById. This is unfortunately the thing that killed my project. All I can see when making the API call is First Name + Last Initial. Even though I can see the full names of all of the users in my web browser, the API won't tell me more. Also, this assumes that a user never changes their name, because then my tracking will break.

API response

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.

Thanks!

[bobbaldhead]

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.

[SkippyVasquez]

@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.

[dblock]

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.