Apps that connect to Strava: how to tell which ones read your data and which just display it

What "connects to Strava" usually means

For most apps, "connects to Strava" means OAuth at sign-up and periodic polling that copies your activity files onto their dashboard. Power, heart rate, and time-in-zone appear; the plan was built from a sign-up questionnaire and never moves. Display is the default because it is the cheap, one-time integration [Strava Developers].

The minimum viable Strava integration is a single OAuth handshake and read access to your activity list. After that, the app pulls your rides on a schedule, renders them, and computes the same summary numbers Strava already shows — average and normalized power, weighted-average heart rate, time-in-zone. This is useful as a log, and it is where most of the market lives. What it does not do is feed those numbers back into anything that decides your training.

The giveaway is that the plan is static. You answered questions at sign-up — hours per week, goal event, current FTP — and the app generated a block from those answers. The rides you actually do afterward are displayed alongside the plan but do not change it. A six-hour week that turned into a two-hour week leaves next week's prescription untouched. The data syncs; the plan does not read it. This is the broader point the pillar on training with Strava keeps making: Strava is the data layer every cyclist already has, and most apps treat it as a journal rather than an input.

None of this is a knock on display-only apps. A clean activity log against a fixed plan is exactly what some riders want, and it is honest about what it is. The problem is only that the Strava-connection badge looks identical whether the app reads your data or merely shows it, so the buyer cannot tell which job the app actually does.

What "reading Strava" looks like from the outside

Reading means the app derives something from your rides that it could not have known at sign-up, then acts on it. Three observable behaviors prove it: FTP estimated from your power history rather than typed in, a plan that changes after an unplanned hard ride, and recognition that a missed week needs a rebuilt next week [Allen et al. 2019, Hellard et al. 2007].

The first behavior is FTP from data. An app that reads your history can estimate threshold power from your last 60-90 days of rides — the shape of your power-duration curve — without asking you to take a test [Allen et al. 2019]. TrainerRoad's AI FTP Detection does this across indoor and outdoor rides with power, including files imported from Strava. If an app only ever uses the FTP you typed at sign-up, it is not reading your power data; it is storing your guess.

The second behavior is plan response to unplanned efforts. Saturday's spirited group ride was zone 4 work whether or not it was on the calendar. An app that reads your rides notices the load and can flag that Tuesday's planned VO2 session is now redundant or risky. An app that only displays will happily prescribe the hard interval on top of the accidental hard ride, because the two events never touched. This is the fitness-fatigue accounting the Banister model formalizes [Hellard et al. 2007] — and it only works if every ride actually moves the ledger.

The third behavior is gap recovery. Miss a week to a sick kid or a work trip and a reading app rebuilds the next two weeks at a reduced volume rather than resuming the original script as if nothing happened. A display app has no mechanism to know the week was missed, because the missing rides are simply absent from a chart, not a signal that triggers a rebuild. The point here is only that the rebuild happening at all is the proof the app read the gap.

The technical tell: webhooks and same-day plan changes

The cleanest objective signal is timing. Strava's Webhook Events API pushes a notification to a connected app within seconds of a ride uploading, and the app must acknowledge within two seconds [Strava Developers]. An app wired for webhooks can change your plan the same hour you finish a ride. A polling-only app waits for its next sync cycle.

Strava offers two ways to get your data: poll the API on a schedule, or subscribe to webhooks that fire on activity create, update, and delete events [Strava Developers]. Polling is simpler to build and fine for a log — the activity shows up whenever the next pull runs, minutes or hours later. Webhooks are the infrastructure of an app that intends to act fast: the moment your ride uploads, the service is notified, parses the file, and adjusts the rest of the week before you have showered.

You can observe this without reading code. Finish a ride, let it upload to Strava, and watch the app. If your plan, your fitness estimate, or tomorrow's session updates within minutes, the app is almost certainly webhook-driven and reading each ride as it lands. If the change takes hours, or only appears after you manually trigger a sync, the integration is polling and probably display-first.

Webhooks are necessary but not sufficient — an app can receive the event and still do nothing useful with it. So pair the timing test with a content test: did the update actually change a decision, or just refresh a number on a chart? An app that webhooks in a ride and then alters tomorrow's prescription is reading and acting. One that webhooks in a ride and only updates a fitness line is reading and displaying. We connect at sign-in, read your full Strava history to seed the plan, and webhook in every new ride so the plan adapts the same day; Intervals.icu reads your history to build a free analytics layer without coaching on top; the difference between those two is the difference between a coach and a dashboard.

The questions to ask before you trust an app with your training

Four buyer-side questions separate readers from displayers, and none requires a trial. Does it estimate FTP from my history or ask me to type it? Does an unplanned hard ride change my next session? Does a missed week rebuild the plan? And does it capture how the ride felt, not just what the sensors recorded [Foster 1998, Haddad et al. 2017]?

Start with FTP sourcing, because it is the fastest to check. If onboarding asks for your FTP and never revisits it from your rides, the app is not reading your power curve. If it estimates a number from your history and re-estimates as you train, it is [Allen et al. 2019]. The same logic extends to heart-rate zones: an app that reads your data can flag a max-HR setting that looks wrong from your actual peaks rather than trusting a formula.

Then probe adaptation directly. Ask the app — or its docs — what happens when you do a hard ride that was not on the plan, and what happens when you miss three days. A reading app has a specific answer: the next session is rescaled, the week is rebuilt, the 80/20 easy-hard balance the plan is built to protect is restored [Seiler 2010]. A display app has a vaguer answer, usually some version of "your activities will sync" — which describes the log, not the response.

Finally, ask whether the app captures context. Power and heart rate are external load; they cannot see the three hours of sleep or the sick toddler behind a flat-looking ride. Carl Foster's session-RPE work is clear that internal load — what the work felt like — explains training response better than external load alone [Foster 1998, Haddad et al. 2017], and the validation literature backs a one-to-ten rating as a metric that stands on its own [Haddad et al. 2017]. An app that asks how the ride felt, and changes its advice based on the answer, is reading a dimension Strava itself does not record. As our companion piece on whether Strava Premium is worth it for a self-coached rider puts it, the gap between syncing your data and acting on it is the gap between a data tool and a coach.

Quick answers

Sources cited in this guide

1. 01
   Strava Developers. Webhook Events API. Strava Developers.
2. 02
   Allen et al. 2019. Training and Racing with a Power Meter (3rd ed.). VeloPress.
3. 03
   Hellard et al. 2007. Assessing the limitations of the Banister model in monitoring training. Journal of Sports Sciences.
4. 04
   Foster 1998. Monitoring training in athletes with reference to overtraining syndrome. Medicine & Science in Sports & Exercise.
5. 05
   Haddad et al. 2017. Session-RPE Method for Training Load Monitoring: Validity, Ecological Usefulness, and Influencing Factors. Frontiers in Neuroscience.
6. 06
   Seiler 2010. What is best practice for training intensity and duration distribution in endurance athletes?. International Journal of Sports Physiology and Performance.

More inside Training with Strava

Other articles in this series

1. 01

   What your Strava Fitness number means (and if yours is good)

   Strava Fitness is CTL — a 42-day weighted load average. What the number means, why it is personal, and the decisions to make from it.

   →
2. 02

   Is Strava Premium worth it for a self-coached cyclist?

   What Strava Premium gives a training-focused rider, what it doesn't (no coaching), and when the free Intervals.icu chart beats paying.

   →
3. 03

   Relative Effort vs TSS: which to trust by workout

   A per-workout-type rule for when to trust Strava Relative Effort vs power-based TSS, and why they are not the same units.

   →
4. 04

   How to set up Strava for training: one-time configuration

   Configure Strava once for training: real FTP and max HR, honest zones, one sensor stack, and feed privacy that protects your plan.

   →
5. 05

   Strava segments as fitness tests: map efforts to tests

   Use Strava segments as scheduled benchmark tests: which profiles map to which test, how to schedule every 4-6 weeks, and controlling variables.

   →
6. 06

   What to look at on Strava after a ride: 4 metrics

   A 30-second post-ride routine: the four Strava metrics that matter after every ride, the ones to ignore, and why.

   →
7. 07

   Strava Fitness going down while training hard: the decay math

   Why your Strava Fitness (CTL) drops even when you train hard: the 42-day EWMA decay math, the real causes, and when a falling line is correct.

   →
8. 08

   Strava indoor power vs outdoor HR: Fitness chart jumps

   Mixing power-based TSS and HR-based Relative Effort splices incompatible units into your Strava Fitness chart. Why it jumps and how to fix it.

   →
9. 09

   Heart rate drift on long rides at same power: what it means

   Why heart rate climbs at flat power on long rides — cardiovascular drift, aerobic decoupling (Pw:HR) as a durability signal, and what to do.

   →
10. 10

    Strava heart rate zones wrong: the whole-dashboard cascade

    How a wrong max HR in Strava cascades into bad zones, Relative Effort, and Fitness — and how to set zones from real data.

    →
11. 11

    Why your Strava Relative Effort is high on easy rides

    Relative Effort can spike on a genuinely easy ride — usually a mis-set max HR, not lost fitness. What inflates it on Strava and what to do.

    →