Calories & Energy data from every wearable, in one schema

Active and basal energy expenditure, normalised to kilocalories and fusible with nutrition intake.

7 / 8

Providers connectable today

5

Webhook events in this family

kilocalories

Canonical units

What calories & energy looks like through one API

Energy expenditure is the most model-dependent number any wearable produces. No consumer device measures calories; every one of them estimates from heart rate, movement, and a demographic model using the user's height, weight, age and sex. Two vendors given identical sensor input will return different numbers, and neither is verifiable without a metabolic cart.

WearLink normalises the units and separates active from basal energy — a distinction providers blur constantly, and the most common source of a doubled daily total. series.basal_energy.created carries resting expenditure; series.energy.created carries active. Summing a provider that reports total against one that reports active only produces a number that is wrong in a way nobody notices for weeks.

Because WearLink also ingests nutrition, the burn side pairs directly with the consumed side through the energy-balance endpoint, which is the actual reason most products want calorie data in the first place.

Where providers disagree

The part that costs you weeks if you build this yourself. None of the following is a WearLink limitation — it is how the underlying providers actually behave.

Active versus total energy is inconsistently labelled

Some providers report only active calories, some report active plus basal as a single total, and the field naming does not reliably tell you which. WearLink splits them explicitly. If you are migrating from a direct integration, this is the field most likely to change value.

Estimates depend on profile data you may not have

Calorie models need weight, height, age and sex. If a user never completed their device profile, the vendor substitutes defaults and the estimate can be off by a large margin. The error is invisible in the payload.

Cross-vendor comparison is not meaningful

Differences of 20–30% between vendors for the same activity are routine and expected. Use energy for within-user, within-device trends and for balance calculations against intake — not for leaderboards across mixed device populations.

Workout calories and daily active calories overlap

A workout record carries its own energy figure, and the day's active-calorie total already includes that workout. Summing them double-counts, and the error scales with how much the user trains — so it is largest for exactly the users who care most. This is one of the most common bugs in fitness products built on aggregated data. Use the daily total as the authoritative figure and treat workout energy as a breakdown of it, not an addition to it.

Providers that supply calories & energy

Status is read from the same provider table the rest of the site uses, so nothing here can claim a provider is connectable when it is not. Coverage also varies by hardware generation within a brand.

ProviderCategoryStatus
FitbitCloud OAuthLive
GarminCloud OAuthOnboarding
WHOOPCloud OAuthLive
OuraCloud OAuthLive
StravaCloud OAuthLive
Apple HealthMobile SDKMobile SDK
Google Health ConnectMobile SDKMobile SDK
Samsung HealthMobile SDKMobile SDK

Webhook events for calories & energy

Subscribe to the summary event for settled records, and to the series streams when you need the underlying samples. Event names below are generated from the backend enum, so they cannot drift out of date relative to the API.

Summary object

calories.created

Series streams

series.energy.createdseries.basal_energy.createdseries.average_met.createdseries.physical_effort.created

Frequently asked questions

Does WearLink separate active and resting calories?
Yes. series.energy.created carries active expenditure and series.basal_energy.created carries basal, so you never have to guess whether a provider total already includes BMR.
Can I compute a daily calorie deficit?
That is what the energy-balance endpoint does — it fuses wearable expenditure with logged nutrition intake into a per-day figure, so you do not have to integrate a separate nutrition service.
How accurate are wearable calorie estimates?
They are model estimates, not measurements, and vendors disagree substantially on identical input. They are useful as consistent within-user signals and unreliable as absolute truth.

Related data types

15 normalised data families in total — see them all or browse integrations by provider.