Reducing my API calls, webhooks and batch requests?

[Eric Keeler]

Hi everyone.

i'm currently in the process of building a site for a well known running shoe brand so that they can run a vitual event leading up to Christmas for their customers. They have the potential to have thousands of people signing up for the event and they want their users to connect with Strava so that they can import their runs throughout the event.

I haven't used the strava API before but after playing around with it this evening it looks like they have a daily API request limit of only 100. Reading through these conversations it looks like it pointless trying to ask SDtrava for an increase.

So, my question is, how can I save and prioritise my calls to the API so that I don't exceed their limits? I've sucesfully managed to install the webhooks feature but this doesn't give me any of the activities data that i require and means that i would have to just make a call to the API for each individualy activities that comes through.

I could do individual calls for each user to grab their runs from a certain date but that would also pump up the number of calls every time someone logs in.

I have seen mentioned about batching requests together and doing one call say every hour that includes all of the activities that have come through the webhook. How would I manage to batch the requests for multiple activities? My tests have just created the same amount of calls as activities.

If there a better way to save on the number of API calls?

Any help would be great as i'd preffer for users to not get errors as we've hit the limit.

Thank for your help

Eric

[Daniel D.]

I have a bot, Slava, that deals with many thousands of Strava users, code is OSS here.   

The strategy is as follows.

1.  Listen on the webhook for events, identifying the athlete and an activity that's created or updated. As you point out, the data in the webhook is insufficient to do anything meaningful with most of the time.
2. If a new activity has been created, queue a user update. This update keeps track of a timestamp of the last well known activity (or a timestamp of when the user was created) and passes an after: value into the requests to Strava. 
3. If the activity itself has changed, update it by fetching it again.
4. Manage rate limit exceeded errors, and avoid sending more requests when that is the case.

Hope this helps.

  

--
You received this message because you are subscribed to the Google Groups "Strava API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to strava-api+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/strava-api/249758c4-8ce6-4bca-9c2a-0272eced940dn%40googlegroups.com.

--

dB. | Moscow - Geneva - Seattle - New York
code.dblock.org - t:@dblockdotorg - ig:@artdblockdotorg - github/dblock