Product Updates
August 2026 product update: per-set strength training data, health context, and a connect widget you style yourself
August 2026: strength workouts arrive set by set on every account, health context predicts missing days with a confidence value, and the connect widget is now yours to style.
TL;DR: Strength training is the hardest thing in health data to represent well, because a set of squats and a ten kilometre run have almost nothing in common. Terra now delivers it properly: strength workouts come through set by set, with repetitions, weight, effort, rest, set types and muscle groups, normalised across ten sources, on every account with nothing to switch on. August also brought Terra's health context feature for predicting missing days with an explicit confidence value, and a redesigned connect widget you style from the dashboard.
Strength training data, set by set, on every account
A lifting session and an endurance session are different kinds of event. One is a sequence of discrete efforts against a load, the other is a continuous effort over a distance, and a product built for lifters needs the first described on its own terms: which exercises, how many repetitions, at what weight, with how much rest in between.
From August, strength data is part of the Unified API on every account. It arrives as a strength_data object on the activity payload you already receive, so there is no new endpoint and no new webhook type. It is null on activities with no strength content, which is most of them, and the only change most integrations need is tolerating one more key.
Inside it, each workout is divided into exercises and each exercise into sets. A set carries the number of repetitions, the weight in kilograms, the load type, the duration, and the rest that followed it. Where the source records effort, you also get RPE, the rating of perceived exertion, which is a one to ten score of how hard the set felt, and RIR, reps in reserve, which is how many more repetitions the lifter could have done. Sets are typed, so a warm-up is distinguishable from a working set, a drop set and a set taken to failure. Exercises carry primary and secondary muscle groups separately, because a bench press trains the chest and also asks something of the triceps, and collapsing the two would imply they were trained equally. A group id marks supersets.
Ten sources report it as of August, spanning dedicated logging apps and watches that detect sets on the wrist. Every one of them reports through the same shape, so integrating once covers the rest. The full list, the payload reference and the guidance on interpreting device-detected sets against logged ones are in the strength training documentation.
One thing to know: to pick up strength_data on workouts you received before August, re-request the activity over the REST API, which returns the same payload with the field filled in.
Health context estimates missing data, and tells you how confident it is
Real health data has holes in it. People take the watch off to charge it, forget to wear the ring, travel without the scale, or simply have a day where the sync did not happen. A chart with gaps reads as a broken product, and an average taken across a month with four missing days is not describing the month the user actually lived.
Health context estimates the missing values across sleep, daily and activity data. What makes it something you can build a product on is that every estimated cell carries its own confidence value. You decide what to do with that: show a high-confidence estimate as a normal point, show a low-confidence one differently or not at all, and exclude estimates entirely from anything a clinician will read. The confidence is reported per cell rather than as a single figure for the whole run, because the run is rarely uniform. A user who wore the device every night but skipped the scale produces a result where the sleep estimates deserve one level of trust and the weight estimates deserve another, and your product should be able to tell them apart.
The connect widget is the screen where your user picks their device and authorises the connection. It is short, it is unavoidable, and it is where you lose people, so how it looks and how few steps it takes matter more than its size suggests.
August shipped a redesign. It is designed desktop-first as well as on mobile, and the outcome screens were rebuilt so that a connection which does not complete tells the user what happened and what to do next, with the guidance drawn from the source catalogue so it is specific to the platform they were connecting.
It is also customisable from the dashboard now, through a customizer page with a test-connection modal, so you can set your logo, your description, the connect button and the title, see the result immediately, and change any of it later without a deploy. The language now comes from the browser's own language preference rather than needing to be passed in.
Also in August
- Google Health is now generally available in connections, having been in preview through the summer. The complete guide to the new Google Health API covers what it changes.
- Sleep payloads now carry an average overnight skin temperature field, which is the input most recovery and cycle features depend on.
- Sleep Window now also returns a regularity score alongside its recommendation, so you can show a user how consistent their timing has actually been, not only what it should be.
- Graphs can now be embedded without an iframe, through scoped npm packages, with a one-command install on React Native. See embedding graphs.
- Android background delivery is now documented on the mobile SDK pages, in mobile-only sources.
- MapMyFitness workouts now arrive by webhook, so a logged session reaches your destination within moments of the user saving it.
- Apple Health: the in-bed window is now reported directly from the source record, which makes sleep efficiency and time-to-sleep exact rather than approximate.
