Provider support & limits

Garmin

Only when the athlete grants historical export on Garmin’s consent screen. We then claim missing activity windows going back sixty months and stop after two consecutive refusals, so the real depth is whatever Garmin still holds for that athlete rather than a number we choose. Wellness summaries are replayed too, but only the last four weeks, which is all Garmin serves. Replayed activities and wellness summaries arrive as ordinary deliveries.

Without the historical export permission nothing is replayed and there is no error to catch — the first delivery is their next activity. Wellness history also needs the health export permission. Windows are paced against an app-wide slot shared with live traffic, so a deep first connection fills in over minutes rather than at once, activities first. Epochs are not replayed.

COROS

COROS’s consent screen carries a checkbox — “allow the third-party app access to your previous workouts within 24 hours”. Left alone it grants 90 days; ticked, it grants the athlete’s whole history, and we walk 30-day windows back up to five years until COROS answers 5011 (“Date out of range”). Nothing in the API says which of the two you got, so the wall is the only signal and the depth is genuinely per-athlete. Replayed activities arrive as ordinary deliveries.

The deep grant expires 24 hours after binding, so history is not something you can offer as a setting later — it is decided on the consent screen and collected at once. COROS also serves only activities recorded on a COROS device: a FIT or TCX the athlete imported through Training Hub is never listed and never pushed, so a gap against their own app is expected.

Polar

Polar’s exercise list returns roughly the last month, and we ingest what it returns rather than paging a window. It runs for Stridee’s own users today and writes first-party rows, so it does not reach a tenant’s event stream yet — the shape COROS was in until its walk started delivering through the shared fan-out.

Polar’s webhook only fires for exercises recorded after registration, so until this ships a tenant’s Polar connection starts at the athlete’s next workout.

Wahoo

Wahoo has no backfill endpoint, so history is a pull rather than a replay: we page the athlete’s workout list from today backwards until it runs out or reaches five years, and deliver each workout through the same fan-out as a live one. Nothing on your side can tell a walked workout from a pushed one.

Wahoo’s quota is per application rather than per athlete — 5000 requests a day for the whole platform — and their list omits the file URL, so a deep history costs one request per workout. Each run takes a bounded slice and a sweep resumes it, so a heavy athlete’s full history can take up to a few days to finish arriving rather than landing at once. Recent workouts come first, and live ones are never delayed by it.

Zepp

Three 30-day windows — Zepp refuses a wider range outright — replayed through the same webhook that carries live workouts, so there is no second code path on your side and no way to tell a replayed delivery from a fresh one.

Zepp’s backfill quota is fifty requests an hour per application, drawn from one bucket by every connection on the platform — about sixteen new connections an hour. Connect a large batch at once and their history fills in over the following hours. Live workouts are never delayed by this.

Hammerhead

Hammerhead publishes a paginated history endpoint, so this is our code rather than their limit. Nothing replays past rides when a rider consents.

A Karoo rider’s first delivery is their next ride.

Fitbit

Google Health lists past workouts and nightly summaries by date, so this is our code rather than their limit. Nothing replays past data when a user consents.

A Fitbit user’s first delivery is their next workout or their next night’s sleep.

No laps and no per-second streams

A delivery carries the activity’s summary. Splits, and the samples behind them, are not exposed on any provider.

No canonical re-encoded FIT

We normalise what a provider sends into one activity shape; we do not re-encode it back into a single FIT file you can hand to another tool.

No automatic delivery retry

A delivery your endpoint refuses stays failed until somebody resends it from the console. Treat a 200 as the only acknowledgement that matters and make your handler idempotent.

Order is not guaranteed

Backfill, provider corrections and retries all arrive out of order. Sort on the activity’s own start time, never on arrival.

Providers you cannot name yet

Apple Watch, Suunto, WHOOP, Oura and Health Connect are designed rather than connectable. Naming one in a POST /v1/connect call is a 400 today. What developers already on the API ask for is what orders them.