Event deduplication across different prodivers

Hi Jurgen,

Thanks for the detailed question.

You’re reading it correctly. In our docs, identifiers like metadata.summary_id (for activity, sleep, planned workouts, etc.) are described as unique per Terra User, that is, per connection to a single health data or wearable account, not globally across every connection you might ever receive.

In our terminology, a Terra User is one such connection (e.g. one Garmin account or one Fitbit account). Your app's End User can have several Terra User_Ids if they connect multiple providers or accounts. So for storage and deduplication on your side, treat each Terra User as its own namespace: e.g. dedupe updates using summary_id together with that connection’s Terra user identifier (and the same idea for types that key on start_time per user, as in the docs). That way you correctly handle replays and updates for each connection without colliding streams from different connections.

If your product model is “one row per night” (or per workout) per person across devices, that merge is application-level: you’ll typically use your own End User key (for example the reference_id you set when linking, which can be shared across multiple Terra Users for the same person) and then apply whatever rules you want (source priority, latest sync wins, etc.). Terra’s dedup logic is about overwriting within the same Terra User when the same logical record is updated, not about choosing between two different wearable accounts for you.

On device prioritization and the dashboard: the safest next step is to open a ticket with support (or your Terra contact) with your use case e.g. multiple connections per reference_id and how you want conflicts resolved and they can confirm whether there’s a supported option for your plan or whether you should implement prioritization entirely in your pipeline.

Hope that helps, and thanks again for building on Terra!