Very much a work in progress…
- your full history will be synchronized into CityStrides, there is no limit to the number of activities that will sync
- there are limits in each service that may cause sync delays
- the Status Page shows some detail on delays
- an activity must first be synchronized into CityStrides, and then it can be processed for completed/progressed streets
- post-sync activity processing has its own queues (which can be delayed; see Status Page Wiki)
- MapMyFitness & Strava provide webhooks, so CityStrides is alerted of each activity after it is saved there
- Runkeeper does not have webhooks, so each sync is a full account sync.
This is a best effort prioritization of how activities are brought into CityStrides. Given the low API limits from Strava, it’s most applicable to users of that service. For other services, there’s a general prioritization placed on subscribers.
- New activities for subscriber accounts
- New activities for regular accounts
- Historic activities for subscriber accounts
- Historic activities for regular accounts
Activity Processing Prioritization
This is how the system weights the different queues. It works through a queue in its entirety before moving onto the next queue. This is all specifically for street progress/completion.
- New users
- Regular users
- Strava’s API limits for requests are 600 every 15 minutes & 30,000 every 24 hours (resetting at midnight UTC)
- I have to self-limit down to 300 every 15 minutes so that syncing can operate 24hrs
- Full history syncing is done by collecting all of the historic activities (this ‘costs’ 1 API request per 100 activities) and then queuing each individually (each individual sync ‘costs’ 1 API request)