Hi all — posting here after exhausting the self-serve path, hoping someone (community or Strava) can give me a signal on what to fix.
Altum Trail Run (altumtrailrun.com) is a training app built exclusively for trail and ultra running. The athlete describes their race, availability and history, and a deterministic engine builds a periodized plan and adapts it week to week from the athlete's own effort feedback. Alongside the plan, the app offers race-day tools: a pacing strategy built from the race course's GPX elevation profile, and a race-nutrition plan — neither of which reads Strava data.
Where Strava fits. The integration does one thing: it saves the athlete from re-typing workouts they already recorded. The app doesn't record activities, and there is no feed, no club, no segment, no leaderboard and no social graph — the athlete keeps recording and living on Strava; the app only reads what they already have, with their consent. Altum doesn't compete with Strava or with any Strava product: everything the app charges for (the periodized adaptive plan, the GPX-based pacing strategy, the race-nutrition plan) is functionality the Strava Platform does not provide within it.
The situation. I'm on the Standard tier (Client ID 222283), at the 10/10 athlete cap — the 11th athlete gets a 403. The app is store-approved on both iOS and Android but held in closed distribution while this request is pending: the Strava connection is offered during onboarding, and I'd rather not launch a feature that fails with a 403 for every new athlete who tries it. I've submitted the capacity-increase form four times (16 Jul, 24 Jul, 30 Jul, 11 Aug 2026) and received the same template decline each time, with no individual feedback.
After each decline I went back to the sources — the Strava API Agreement (strava.com/legal/api), the Strava API Policy (strava.com/legal/api_policy) and the Strava Brand Guidelines (developers.strava.com/guidelines) — re-read them clause by clause, and changed the app to match: scope reduced from activity:read_all to activity:read, webhooks instead of any polling, a 7-day purge of cached identifiers, full deletion confirmed on screen and by email when the athlete disconnects from either side, a consent disclosure at every OAuth entry point, and the official Connect with Strava and Powered by Strava assets, unmodified, on every surface that shows imported data. The full clause-by-clause summary is public at altumtrailrun.com/strava-api-compliance. All of this was explained in the submissions themselves, with evidence: the latest one included 17 screenshots covering every surface where Strava data appears — the consent screen shown before authorization, the Connect with Strava buttons, the attribution on every list and detail view, and the connected-account settings with the disconnect flow. To the best of my reading the app now follows every guideline to the letter — which is exactly why a fourth identical template decline leaves me with nothing to act on.
Reference pages (all static, served in four languages): Privacy Policy — altumtrailrun.com/privacy · Terms of Service — altumtrailrun.com/terms · Strava integration summary, written for review — altumtrailrun.com/strava-api-compliance
My questions:
1. The decline template lists four possible reasons (not complementary / API use not optimized / security-privacy concerns / non-compliance) without saying which applies. Is there any channel through which a declined applicant can learn which area failed? Four submissions have produced zero actionable information, and "resubmissions are not guaranteed a different outcome" is hard to act on when I don't know what to change.
2. I can't map the decline to any of the four. API use: webhook-driven, no polling, rate-limit headers honored. Security/privacy: consent before authorization, 7-day purge, full deletion confirmed, all documented at the compliance page. Compliance: audited clause by clause, as above. That leaves complementarity — the only one of the four that is a judgment call on Strava's side rather than something I can audit in my own code. I'm not assuming that's the reason; it's just the only one I can't check myself. Is there any guidance on how it's evaluated for training apps?
3. Does anyone see a known red flag in the package above that the template letter would map to?
I'm happy to provide TestFlight / Play internal-testing access, screenshots, or any documentation a reviewer wants. Thanks for reading.
