Product Updates
January 2026 product update: Planned Workouts v2, and two new activity scores
January 2026: Planned Workouts v2 rewrites how structured sessions are pushed to devices, two new activity scores land, and rate limits are finally written down.
TL;DR: Planned Workouts was rebuilt in January. If you are writing training sessions out to a user's watch, the second version gives you one way to describe a session and tells you exactly what each destination platform accepted and what it adapted, so nothing about the athlete's session is a surprise to either of you. Two new activity scores, RCRS and TRIMP, arrived in the same month, and Terra's rate limits and a complete example payload are now published in the documentation.
Planned Workouts v2: write a structured session once, send it anywhere
The Planned Workouts API is the part of Terra that runs in the opposite direction from everything else. Rather than reading what a person did, it writes what they are supposed to do to their watch or training platform, so when they start the session the intervals are already there, and the watch counts them down.
This is the sort of feature that sounds simple but isn't, because every destination platform models a workout slightly differently. Some describe a step by duration, some by distance, some by a heart rate or power target, some by all three. Some support nested repeats to arbitrary depth and some support one level. Some accept a rest step and some expect you to express rest as a very low intensity work step. If you write directly against each one you end up maintaining several incompatible mental models of what a workout is.
Our new feature update reworks this. You describe the session once, in Terra's model, and Terra translates. Where a destination cannot represent exactly what you asked for, it returns a coercion warning telling you what it changed and why, so you can decide whether to accept the approximation or show the user a different plan on that platform. The warning is the important part. A translation you can see is a translation you can design around, which means your product decides what the athlete sees rather than finding out alongside them.
The full model, the per-platform support matrix, and the coercion warnings are documented in the Planned Workouts API overview, with the platform-by-platform detail in provider compatibility.
Two new activity scores: RCRS and TRIMP
Terra's health scores turn raw physiological numbers into a single interpretable figure, computed against the person's own recent baseline rather than against a population average. January added two that describe a single workout.
TRIMP stands for training impulse. It is a long-standing sports science measure that multiplies how long a session lasted by how hard the heart was working during it, weighted so that time spent at high intensity counts for disproportionately more than time spent easy. The practical use is comparing sessions that are not otherwise comparable: it lets you say that a short, very hard interval workout and a long, easy ride carried a similar cost.
RCRS is a relative cardiac response score. Where TRIMP asks how much load a session carried, RCRS asks how the person's heart responded to it relative to their own recent maximum, which makes it useful for spotting the days where a familiar session felt unusually hard.
Both arrive inside the activity payload under data_enrichment, and both are listed with the inputs they require in the Health Scores documentation.
Send only the data a user entered by hand
Some products only care about what the person typed. A nutrition app usually wants the meals the user logged and has no interest in the passive step count that arrives alongside them. A destination can now be set to manual data only, which filters the stream down to entries the user created themselves rather than readings a sensor produced in the background.
This pairs with the existing ability to choose which data types each destination receives. Between the two, the volume arriving at your endpoint can usually be cut by a large factor without losing anything you were going to use.
Rate limits and a complete example payload, written down
Terra's rate limits, and a realistic example payload showing what a webhook body looks like in full, were published in January. Both belong in the documentation rather than in a support thread. Knowing your headroom in advance is what lets you size a nightly job properly the first time, and a complete payload, including the fields that are null for most users, is what lets a team write their parser against the real contract rather than against a sample that happens to be populated.
Both are in the Unified API overview.
Also in January
- Virtuagym and MacrosFirst joined the source catalogue, covering gym management and nutrition logging respectively.
- Webhook events are now categorised, which makes routing on your side a matter of reading one field rather than pattern matching on the event name.
- Sources that report a wall clock time with no zone attached are now supported end to end, which widens what Terra can normalise without discarding or inventing a timestamp.
- Destinations can now be configured before they are reachable, so you can wire up an endpoint that lives inside a private network and validate it when it goes live.
