> For the complete documentation index, see [llms.txt](https://docs.tryterra.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tryterra.co/help-center/help-topics/data-api-sdk/historical-data-and-backfill/mobile-native-no-backfill-sdk-fetch.md).

# When is historical data available after connect?

Mobile-native sources read from data stored on the user's phone, not a cloud history.

[Mobile-native sources](https://docs.tryterra.co/health-and-fitness-api/mobile-only-sources) read from data stored on the user's phone, not a cloud history.

* **Apple Health** does not auto-backfill on connect. The app must call the SDK fetch methods (`getActivity`/`getDaily`/`getBody`/`getSleep`) with a date range, and a completion callback signals when history is pushed.
* **Samsung Health** likewise syncs forward from the link date. To pull older data, use the same SDK date-range methods at connection time, but reach is limited to the recent window Samsung Health still holds on the device, not the full lifetime.
* Each relink starts a fresh connection with a **new Terra user ID**, so older data sits under earlier connection instances.
* **Cloud providers** work differently. When a new connection is created, Terra fetches recent history in the background: up to a year for most providers, within each provider's own limits, and 7 days for Fitbit, WHOOP, Strava and Withings. Garmin only allows this when the user granted its historical data permission. That history is returned by the REST API but isn't sent to your destination, so [request a date range](https://docs.tryterra.co/health-and-fitness-api/managing-user-health-data/requesting-historical-data) with `to_webhook=true` to receive it.

The REST API returns what the device has already pushed, and `end_date` is **exclusive** (use the next day to capture a full day).