Nutrition & Food Logging API
Nutrition & Energy Balance data from every wearable, in one schema
Photo-based meal recognition with per-dish macros, fused with wearable burn into daily energy balance.
3/3
providers connectable today
1
webhook event types
Canonical unit
grams for macros, kilocalories for energy
What nutrition & energy balance looks like through one API
Nutrition is the half of the energy equation wearables cannot see. A device measures expenditure; it has no idea what went in. Products that want to show a deficit have historically had to integrate a second vendor for food logging and then reconcile two incompatible daily boundaries themselves.
WearLink ingests nutrition directly. A user uploads a meal photo, the vision pipeline returns per-item dishes with grams and macros verified against a curated food database, and the result lands on the same event bus as the wearable data. Three webhook events cover the lifecycle: nutrition.log.created when the photo is accepted, nutrition.log.recognized when recognition completes, and nutrition.log.corrected when a user edits a result.
That correction event is the one most teams underuse. Every user edit is a labelled example — which dishes your population eats, which the model gets wrong, and where portion estimates drift. It is a training signal delivered as a webhook.
The food database is weighted toward Indian and South-Asian dishes as well as Western plates, because most nutrition APIs are built on US-centric databases and fail on a thali, a masala dosa or a paneer butter masala. Low-confidence recognitions route to human review rather than guessing.
Where providers disagree
Intake and expenditure use different day boundaries
Wearable days are bounded by device-local midnight; meal logs are bounded by when the user actually logged. A late-night meal logged after midnight lands on the wrong side of a naive join. The energy-balance endpoint applies one consistent boundary to both sides.
Portion estimation is the dominant error source
Dish identification from a photo is comparatively reliable; estimating grams from a two-dimensional image is not. Expect portion to be the field users correct most, and design the UI so correcting it is one tap rather than a form.
Regional coverage varies by database, not by model
Recognition quality tracks whether the dish exists in the underlying food database. A dish absent from the database cannot be scored no matter how clearly it is photographed, which is why the regional curation matters more than the vision model.
Webhook events for nutrition & energy balance
Summary: nutrition.log.created
The full catalogue is in the event catalogue.
FAQ
Nutrition & Energy Balance — frequently asked questions
How does photo-based meal logging work?
Does it handle Indian food?
What happens to photos and location data?
Can I combine nutrition with wearable calorie burn?
Get nutrition & energy balance from every device your users own
Free for up to 3 connected users. No credit card. Your first API key is issued the moment you sign up.