Calorie Tracking API: How to Get Calorie Data

Calories burned: where you can get it (and why it's an estimate)#

Lead with the caveat: calories burned are modeled estimates, not measurements. The same workout yields different numbers on different devices because each vendor uses a proprietary algorithm over heart rate, motion, activity type, and user profile (age, weight, sex). Basal/resting energy in particular is a modeled baseline from a BMR formula, not anything sensed live. Never publish an accuracy percentage — none is sourced — and treat every field name below as "as of 2026, verify" against the provider's live data dictionary.

The developer gotcha here is active versus total. On HealthKit, activeEnergyBurned and basalEnergyBurned are separate — sum them yourself if you want an all-day total, and don't double-count against a workout's totalEnergyBurned. On Health Connect, TotalCaloriesBurnedRecord already includes basal while ActiveCaloriesBurnedRecord does not, so mixing them, or summing across apps that populate them differently, will inflate the number. Verify how each source populates these before you add anything up.

Calories consumed: this needs a nutrition API, not a wearable#

No wearable, phone sensor, or on-device motion model can tell you what someone ate. Calories consumed comes from food-logging against a nutrition database, which means a dedicated REST API:

• Nutritionix — a food/nutrition database with natural-language food logging. Verify current endpoints, pricing, and terms in its developer docs.
• Edamam — a Nutrition Analysis API that parses natural-language food ("1 cup rice, 10 oz chickpeas") and returns calories plus roughly 28 macro- and micronutrients, with a food-logging nutrition mode. Verify current fields and quotas in its docs.

You can also store and read logged intake on-device: HealthKit exposes dietary energy (dietaryEnergyConsumed) and Health Connect has a NutritionRecord — verify exact field names in each platform's data dictionary. But those are stores for intake a user or app already logged, not a source of nutrition facts; the facts still come from a nutrition database. Compare providers in nutrition APIs rather than duplicating that here.

Measured or estimated?#

• Calories burned: estimated / modeled. Derived from heart rate, motion, activity type, and user profile via proprietary per-vendor algorithms. Numbers disagree across devices for the same activity; basal energy is a formula-based baseline. Say this plainly to your users and never present it as a measurement.
• Calories consumed: as good as the food database and the user's logging. A nutrition API returns database values for the item logged — accurate for the matched food, but dependent on the user picking the right item and portion. It is a lookup, not a measurement of the specific meal.

Neither figure is sensor ground truth. Framing calorie data as a precise readout is misleading; treat both as wellness estimates.

Which should you pick?#

• Calories burned, widest coverage: read the on-device platform energy types (active + basal on HealthKit; active + total on Health Connect) so you inherit whatever a paired wearable wrote. Keep on-device data on the user's phone until you choose to upload it.
• Calories burned, server-side: pull from the wearable vendor's cloud API or an aggregator when you need the data without the user's phone in the loop.
• Calories consumed: a dedicated nutrition API — Nutritionix or Edamam. A wearable API will never give you intake, so this is a separate integration.

Before you ship#

Re-verify each provider's current energy field names, records, and OAuth scopes against its live data dictionary — these change. Distinguish active from total/basal so you don't double-count. Be explicit with users that calories burned are a modeled estimate that varies by device, and that calories consumed depend on a nutrition database plus accurate logging. For the mechanics of the burn estimate itself, hand off to how fitness apps estimate calories.