The Hub is now in read-only mode as we make improvements to the Hub experience. More information is available here.
01-06-2024 07:04 AM
I'm super curious how developers are bootstrapping their data.
When starting a new app, I want to bootstrap my database with my personal history. So rather than simply leveraging webhooks, I want to first read in past events. This is impossible with the current rate limits.
What do most people do to solve this problem?
Thanks!
Solved! Go to Solution.
01-11-2024 02:14 PM - edited 01-11-2024 02:16 PM
It really depends which data fields you are trying to collect. You can use getLoggedInAthleteActivities to retrieve up to 200 activities at a time using a single API call, so even for someone doing 2-3 activities per day that would only require 5 API calls for a year of activities. If you're pulling activity streams or other details which aren't included in the SummaryActivity model then you'll have to do things the hard way and grab a single activity at a time, which leads to...
You can (and should) also design your app with rate limiting built in. Every API call returns your current rate limits and usage in headers. You can use that information to throttle your calls to stay within your limits. For my app I have queues of pending requests and only pull from them if I have enough API calls left to complete it, otherwise I wait for the next 15 minute increment before executing an API call. That allows me to handle any sudden influx of activities without blowing through my API limit. It occasionally adds a little bit of processing delay for the end user during very busy times, but it's better than failing to process at all.
01-14-2024 09:57 AM
Thank you for the pointer to getLoggedInAthleteActivities!
01-11-2024 02:14 PM - edited 01-11-2024 02:16 PM
It really depends which data fields you are trying to collect. You can use getLoggedInAthleteActivities to retrieve up to 200 activities at a time using a single API call, so even for someone doing 2-3 activities per day that would only require 5 API calls for a year of activities. If you're pulling activity streams or other details which aren't included in the SummaryActivity model then you'll have to do things the hard way and grab a single activity at a time, which leads to...
You can (and should) also design your app with rate limiting built in. Every API call returns your current rate limits and usage in headers. You can use that information to throttle your calls to stay within your limits. For my app I have queues of pending requests and only pull from them if I have enough API calls left to complete it, otherwise I wait for the next 15 minute increment before executing an API call. That allows me to handle any sudden influx of activities without blowing through my API limit. It occasionally adds a little bit of processing delay for the end user during very busy times, but it's better than failing to process at all.
Welcome to the Community - here is your guide to help you get started!