How much history you actually get: backfill limits by provider
Pricing pages list "historic health data retrieval" as a feature with no number next to it. The documentation underneath has the numbers, and for some providers it is four weeks. That gap decides what your first session can show a user.
- Backfill depth is set by each provider, not by your vendor.
- Some providers give 180 days. Some give 28.
- Heart-rate history is often shorter than everything else, even where sleep goes back months.
- If you need a baseline, somebody has to hold history over time. It does not have to be you.
| Provider | Backfill | The catch |
|---|---|---|
| Oura | Up to around 180 days | Heart rate often much shorter |
| Whoop | Up to around 180 days | Docs advise against requesting more than 30 at once |
| Fitbit | Up to around 90 days | Some time-series may cover only 30 |
| Garmin | Up to around 90 days | One backfill per user per application, up to 12 hours, events may arrive out of order |
| Withings | Up to around 90 days | Advise against large requests |
| Polar | Around 28 days | — |
| Suunto | Around 28 days | — |
| Health Connect | 30 days before permission was granted | Reinstalling resets the window |
Figures as published in aggregator documentation at the time of writing, and they change. Treat this as the shape of the problem, then confirm against current provider docs before you design around any single row.
Limits are usually per application, not per user, so they get tighter as you grow. One provider documents 100 requests a minute and 10,000 a day against the API key. Polling one endpoint hourly for a thousand members is 24,000 requests a day — over that limit before you have backfilled anything or retried anything.
The practical failures to design for: 429 on limit, 424 when the provider rate-limits underneath your vendor, and a 504 when a synchronous historical fetch runs past the timeout. Large requests generally have to go asynchronous and come back on a webhook.
A user connects and expects to see something about themselves. What you can show is decided by that table, not by your product design.
- Design the empty state for 28 days, not 180
- Treat a missing night as null, never as zero
- Store the day boundary with its timezone at capture
- Expect out-of-order and duplicate events
- Promise a user "six months of history" generically
- Assume the pricing page bullet is the spec
- Compare one brand’s score with another’s
- Run backfill on the same budget as steady-state polling
Humotron reads the last six months of daily summaries once, at connection, within whatever each provider actually allows, and holds the baseline over time so the partner does not have to. You get the ranking and the reason, not the history.
Why is Apple different?
Apple Health has no server-side REST API. Access is on-device, which means a native app in the flow rather than a server-to-server call. That is a product constraint, not a vendor one.
Can we extend backfill by paying more?
Not usually. The ceiling is the provider’s, so no aggregator can sell you past it.
How long until a baseline is useful?
It depends on the signal and the person. The relevant point is that a baseline is built forward from consent, so whoever holds it needs to be holding it continuously.