Athlete Capacity is 99 - this is far too low and I'm extremely concerned

[Bunsen]

Hi there,

I have just had my submission approved for the Strava Developer program. In the e-mail, it included that I now have rate limits that are higher than they previously were, which is great. However, it included that my "athlete capacity" is now only 99 - whereas previously it was unlimited for all API applications.

I already have 96 athletes connected - you can see how many you have once approved. This limit of 99 is far too low and I am extremely concerned. It reads as though my application, among many others, has/have just been broken for new users.

I have a bunch of questions: 

• What happens if I reach the 99 athlete limit and another tries to connect? What is the error message so that this can elegantly be handled?
• How am I supposed to deauthorize an athlete? My application is a visualization app which has very few concurrent users. However, it may have many connected athletes as they will connect, use the application, and likely forget about it. This seems like an obvious and serious fault of this approach of limiting athletes - the number of connected athletes does not necessarily reflect the scale of the application. I may get and lose a new user every day for a year. The actual athlete usage of my app has not changed, yet my utilized capacity has grown since they do not deauthorize.
• How can I appeal to have this limit raised?

The e-mail contents I'm referring to:

Moving forward, here’s what you can expect for your app:

Overall Rate Limit: allows for 600 requests every 15 min, with up to 6,000 requests per day
Read Rate Limit: allows for 300 requests every 15 min, with up to 3,000 requests per day
Athlete Capacity: 99

[kimbad]

My app has been approved as well with exactly the same limits. I previously had a limit of 30,000 requests per day so it looks like they are setting a standard amount. The new limit makes it almost impossible for my app to work under the T&C of the api as I am caching man y segments to improve performance but these need to be refreshed every 7 days to comply. How do we reach out to request a change?

[Elliott]

Hi there, 

Thanks for submitting to the developer program!

We appreciate the questions surrounding athlete capacity for your app - if you'd like to reach out to us at developers@strava.com, our team can take a look.

Thanks! 

[Bunsen]

Hi Elliot,

I did write in and am in the process of hopefully increasing my athlete capacity before the application fails.

I do want to provide feedback that I strongly disagree with the introduction of this metric, or at least the ratio (6,000 requests to 99 athletes).

For me, 6,000 API requests are far more than I will likely ever need. 1,000 was OK and 2,000 would have been probably perfect. However, a connected athlete capacity of 100 is absurdly small. I worry that these changes were made with a specific app type in mind, and a complete blind spot for a majority of applications, like mine.

Based on the reply by @kimbad, that their application has decreased from 30,000 to 6,000, I am concerned that new standard limits are being applied without consideration for each application. I would advise anyone to not apply to this program before things are ironed out.

One additional point as to why I disagree with this metric: if we need to deauthorize users (to not make our applications fail by exceeding capacity) by the endpoint using their access token that means that all applications will now need to store athlete's access token's server-side. This seems antithetical to the purpose of the program regarding athlete privacy, as not every application needs the developer to know every users access token. In my example, I only stored athlete access tokens securely and locally on their device - now I will need to store them in a way that I will personally have access to them.