> 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/faq/help-topics/data-api-sdk/webhooks-dedup-and-sync-reliability/originating-source-via-device-data.md).

# Can a payload show its originating source through an aggregator?

It depends on the provider.

* **Apple Health:** the originating app is identifiable via `device_data.name` on the activity payload (for example `Polar Flow`). For daily/body/sleep, contributing sources appear across `device_data.name` and `device_data.other_devices` combined. Activity and sleep are keyed by HealthKit/source UUID as `summary_id`, so different sources never overwrite each other.
* **Health Connect (Android):** `device_data` is not currently populated for any data type, so a source coming through Health Connect is indistinguishable.
* **Withings:** `device_data.name` reflects the origin of each activity, which may be a connected third-party app (Google Fit, Samsung Health, HealthKit) rather than a physical Withings device, because Withings aggregates connected sources. `metadata.upload_type` value `6` indicates a third-party origin. Withings Body payloads don't currently carry `upload_type` or a populated device name.

See the [data models reference](https://docs.tryterra.co/reference/health-and-fitness-api/data-models) for the full payload structure.