Best practices for managing rate limits when tracking near real-time leaderboard changes across cycling and running segments
Hey all, looking for some guidance from developers who have solved this problem or from the Strava team directly.I'm building a segment discovery app (Segment Sniper) that helps athletes find segments with beatable leaderboards for both cycling and running. One of the features I'm working on is alerting users when their KOM, QOM, or CR position is under threat or has been taken.The challenge is getting leaderboard data frequently enough to detect changes without blowing through the rate limits (200 requests per 15 minutes, 2,000 per day).Here's what I'm currently thinking:1. Using webhooks (POST /push_subscriptions) to detect when any of our users uploads a new activity. When a webhook fires, I check which segments overlap with that activity and refresh only those specific leaderboards. This avoids polling entirely for activity detection.2. For leaderboard monitoring on segments where our users hold positions, I'm batching GET /segments/{id}/leader
