Skip to main content
Question

Requesting more capacity on a pre-restructure allocated Standard Tier — does this go through Extended Access review now?

  • August 8, 2026
  • 6 replies
  • 81 views

Forum|alt.badge.img+1

Hi all — solo dev, in case some of you have hit this road block and can save me guessing….

 

I run My Running Dashboard (myrunningdashboard.com), an analytics dashboard for club runners — training load, relative fitness level, historical data context, race predictions over multiple distances - that kind of thing. Client ID 213283.

 

Grandfathered on the pre-June-1 Standard Tier (999 athletes / 3,000 daily reads), currently at ~250 athletes, growing by word of mouth, currently in free beta stage while I polish it.

 

I have submitted two applications this year asking for more daily reads within that existing allocation — not trying to move up to a new category, just more headroom on what I already had. May’s was maybe slightly speculative on numbers; August’s had real measured telemetry (peak-day reads, a documented traffic surge, an audit of every backfill-triggering code path). Both rejected, the first after many weeks wait, this latest one in just 4 days with the standard generic potential reasons list, no specifics. I can’t see anything obviously wrong with my application and there is no indication Strava are unhappy with it as the 999/3000 capacity remains in place.
 

Given the new tier language, I’m not actually sure what I applied into. Is a request like mine — more capacity on an existing pre-restructure grandfathered allocation — now evaluated as an Extended Access application by default, since that’s the only tier offering “greater user capacity”? Or is there a distinct process for legacy accounts that I’m missing?

 

Has anyone at similar scale (low hundreds of users, solo/indie, not a company) gotten a capacity increase through post-restructure? Trying to work out if another attempt is worth the effort or if I should just plan around the current allocation permanently.


A huge amount of effort has gone into MRD and this rejection without reason is quite disheartening.

 

Thanks — happy to give more detail if useful.

6 replies

Jan_Mantau
Forum|alt.badge.img+26
  • Hub Powerhouse
  • August 8, 2026

The tiers are defined by the number of connected users only, the other rate limits are independent. That means you are on standard tier and you can see that in the Strava API dashboard.

If 3000 reads a day are not enough for 250 users Strava is most likely on the position you should optimize the usage first, but nowadays you don’t get clear answers from them.


Forum|alt.badge.img+1
  • Author
  • Hub Rookie
  • August 8, 2026

The tiers are defined by the number of connected users only, the other rate limits are independent. That means you are on standard tier and you can see that in the Strava API dashboard.

If 3000 reads a day are not enough for 250 users Strava is most likely on the position you should optimize the usage first, but nowadays you don’t get clear answers from them.

Yeah but have optimized hugely already since the first application and documented it in the application.


Forum|alt.badge.img+1
  • Author
  • Hub Rookie
  • August 10, 2026

Have optimised further now and gained a little room for manoeuvre. So I’ll try to get closer to the 999 before re-applying.

But it’s still guesswork. What if it’s something completely different that triggered the rejection?

 


Forum|alt.badge.img
  • Hub Starter
  • August 11, 2026

Sorry to hear about the rejection. One thing worth clarifying with Strava may be the underlying use case rather than the capacity tier.

Being grandfathered on the pre-June API allocation does not necessarily mean being grandfathered out of the API Policy that took effect on 1 June. Your website and privacy policy say that MRD imports and retains an athlete’s complete Strava history, stores raw and derived data for the lifetime of the account, and uses it for training-load analysis, fitness tracking and race predictions.

On the face of it, that appears difficult to reconcile with sections 5.4, 5.5 and 6.2 of the new policy. Those provisions prohibit using Strava Data and derived data for analytics or analyses, prohibit persistent archives or databases, and limit caching to seven days.

Could the capacity requests be getting rejected because the application is being assessed against the new permitted-use rules? It may be worth asking Strava directly whether MRD’s retention and analytics model remains permitted before spending more writing another application.


Jan_Mantau
Forum|alt.badge.img+26
  • Hub Powerhouse
  • August 11, 2026

The current API policy applies to every app regardless of creation date. Most rules including Strava data storing and caching did exist prior to June anyway.


Forum|alt.badge.img+1
  • Author
  • Hub Rookie
  • August 11, 2026

Thanks — yes, that’s the ambiguity I’ve been wrestling with since the June policy change. I don’t think the wording of these sections is easy to reconcile with athlete-facing training analytics and I agree it’s something Strava needs to clarify.

The frustrating part is that the rejection gives no indication whether this was the issue at all, or whether it was simply rate-limit/capacity policy. Since my existing access ( 999/3000 ) remains unchanged, I’m skeptical about inferring a compliance finding from generic boilerplate response.

Am also skeptical that asking directly would even result in a response.