--- title: "Nutrition APIs Compared: Where Calorie Numbers Come From — Tiny Plates" description: "Nutrition API comparison: USDA, Edamam, Nutritionix, Spoonacular, Open Food Facts and Tiny Plates. Where the calories come from and what each costs." url: "https://www.tinyplates.dev/blog/nutrition-apis-compared" --- # Nutrition APIs compared: where the calorie numbers actually come from USDA, Edamam, Nutritionix, Spoonacular, Open Food Facts and Tiny Plates, and why their numbers don't agree. 20 October 2026 Every nutrition API gives you a number like "475 kcal". It looks precise. It almost never is. And two APIs can give you very different numbers for the same dish, because they got them from different places. If you're building a fitness app, a diet tracker or a meal planner, it helps to know where those numbers come from. So let's follow them back to the source. Then we'll compare the main APIs, including ours, and be honest about what each one is good for. ## Where the numbers come from Almost every calorie figure you'll ever see comes from one of three places. The first is **lab analysis**. Someone took a food, like raw broccoli or cooked rice, and measured what's in it. National food tables are built this way. In the US that's the USDA's FoodData Central. Many countries have their own, like the UK's CoFID or Sweden's food database from Livsmedelsverket. These are the gold standard for basic foods. They're also where most other APIs get their data in the end. The second is **package labels**. A manufacturer prints a nutrition panel on the box, and a database copies it. The USDA's branded foods data works like this, and so does Open Food Facts, where volunteers type in labels. Labels are good, but they're rounded and they're allowed some wiggle room by law. The third is **calculation**. Take a recipe, match each ingredient line to a food in one of the tables above, add it all up and divide by servings. This is how most recipe nutrition is made, whether a website does it or an API does it for you. That third one is where things get fuzzy. Take "2 pounds chicken breast". Raw or cooked? Cooked chicken has lost water, so 100 g of it has more calories than 100 g raw. Take "1 medium onion". How big is medium? Take "salt to taste". How much is that, really? Take "serve with rice or naan". Is that in the number or not? And "serves 4 to 6" means the per-serving number can move by half depending on who picked 4 or 6. None of these have a right answer. Every calculator makes guesses. Good ones make sensible guesses and write them down. So when two APIs disagree by 20% on a lasagne, neither is lying. They just guessed differently. Here's a real example. We searched Tiny Plates for "chicken tikka masala" and got three recipes back. Per serving, as their sites published them: 249 kcal, 475 kcal and 738 kcal. Same dish name. One is a lighter recipe with a 3/4-cup serving. One is made with heavy cream and butter. The third has 80 g of carbs a serving, so it may well count the rice on the plate. All three numbers are "right" for what they describe. ## The APIs, side by side | API | Where its numbers come from | Free option | Best for | | ------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------ | | USDA FoodData Central | Lab analysis, survey data and branded labels | Yes. Public domain, 1,000 requests an hour | Single foods, building your own calculator | | Edamam Nutrition Analysis | Calculated from your ingredient lines against its own food database | No. From $29 a month, 10-day trial on the smallest plan | Analysing recipes users type in | | Nutritionix | Its own database of common, branded and restaurant foods | No public free tier. Trial on request | Food logging from plain-language text | | Spoonacular | Calculated from ingredients with its own algorithm | Yes. 50 points a day, backlink required | Recipes and nutrition from one API | | Open Food Facts | Package labels, entered by volunteers | Yes. ODbL, no key | Barcodes and packaged food | | FatSecret Platform | Its own food database | Yes. Basic tier, 5,000 calls a day, US only | Food logging, a big US food list | | Tiny Plates | The label the recipe's own site published | Yes. 50 requests a day | Showing recipes with their nutrition | Prices and limits were checked in October 2026\. They change, so check each pricing page before you commit. **USDA FoodData Central** is where we'd start if you want to understand the numbers. It's free, it's public domain under CC0, and it's the source many other APIs build on. It has a few kinds of data. Foundation Foods and SR Legacy are analysed basic foods. FNDDS is foods as Americans actually eat them, like "chicken curry". Branded Foods is label data from manufacturers. You need a free data.gov key, and the default limit is 1,000 requests an hour. ```bash curl 'https://api.nal.usda.gov/fdc/v1/foods/search?api_key=DEMO_KEY&query=chicken%20breast%20raw' ``` What it doesn't do is read a recipe. If you want nutrition for "2 cups flour, 3 eggs", you parse the lines, pick the right food for each, convert cups to grams, and add it up. That's real work. We wrote about the first step in [parsing ingredient lines](https://www.tinyplates.dev/blog/parse-ingredient-lines). **Edamam Nutrition Analysis** does that work for you. Send ingredient lines and it sends back calories, macros and micronutrients, line by line. It's good at it. But there's no free plan. The smallest plan is $29 a month with a 10-day trial. Attribution is required on every plan. And watch the caching rules: on the smallest plan you can't cache results at all, and the next plan up only allows a few figures like calories and protein. **Nutritionix** is built for food logging. Its natural-language search turns "a big mac and a coke" into nutrition, and it knows a lot of restaurant and branded items. Its developer site now says it can't keep a public free tier going, so you'll need to ask for a trial. It's a strong pick for a calorie tracker if you can pay for it. **Spoonacular** works out recipe nutrition from the ingredients, using its own food data. The nice part is you get recipes and nutrition from one API, and it can analyse recipes you send it too. The free plan is 50 points a day with a backlink. Paid plans start at $29 a month. Note the caching rule: most data can only be kept for an hour. More in our [Spoonacular alternatives](https://www.tinyplates.dev/blog/spoonacular-alternatives) post. **Open Food Facts** is the one for anything with a barcode. The nutrition comes straight off the package, typed in by volunteers. It's free and open under the ODbL, so you share alike and give credit. Data quality varies by product, since it's crowdsourced. Popular products are usually well checked. Obscure ones may have gaps. **FatSecret** has a free Basic tier with 5,000 calls a day, US foods only, and attribution required. Startups, non-profits and students can apply for a bigger free plan. ## What Tiny Plates gives you We should be clear here, because it's a bit different from the rest. Tiny Plates doesn't calculate nutrition. We pass on what the recipe's own website published. Many recipe sites put a nutrition label in their page markup, using schema.org. We read it, clean it up and give it back in one shape. Kilojoules become kilocalories. "610mg" becomes a number and a unit. If a site publishes no nutrition, the recipe has no `nutrition` object. We don't fill the gap with a guess. Here's that tikka masala again, asked for 6 servings: ```bash curl 'https://api.tinyplates.dev/recipes/69e228cbd0295ac8a9011c22?servings=6' \ -H 'Authorization: Bearer rd_your_api_key' ``` The recipe has its `nutrition` as published. Next to it you get `nutritionTotals`, which tells the same numbers two ways: ```json "nutritionTotals": { "servings": 6, "basisServings": 4, "perServing": { "calories": { "value": 475, "unit": "kcal" }, "protein": { "value": 38, "unit": "g" }, "sodium": { "value": 745, "unit": "mg" }, "source": "provided" }, "perRecipe": { "calories": { "value": 2850, "unit": "kcal" }, "protein": { "value": 228, "unit": "g" }, "sodium": { "value": 4470, "unit": "mg" }, "source": "provided" } } ``` A few things are going on. `perServing` stays at 475 kcal when you scale. More servings of the same food is the same plate. `perRecipe` is the whole pot, and it grows with the scaling. `basisServings` says the site worked its label out on 4 servings. That matters, because this recipe says "4 to 6". We store 4, but some sites with a range work the label out on the top end, and we follow their label, not our guess. `source: "provided"` means it came from the site. You get calories, fat, saturated fat, carbs, sugar, fiber, protein, sodium and cholesterol when the site gives them. Some sites also give micronutrients, like potassium or vitamin C, and those come through in `micronutrients`. Now the limits. Please read these before you build on it. * **Not every recipe has nutrition.** Only the ones whose sites published it. Many do. Plenty don't. * **We can't check the numbers.** Each site made its own label, with its own calculator and its own guesses. One might count the rice. One might not. We pass it on as is. * **Some labels are per 100 g.** We keep them, and `basis.type` says `100g`. But we can't turn those into per-serving numbers without knowing the dish's weight. So those recipes get no `nutritionTotals`. * **Nutrition filters aren't on the free plan.** The API has filters like `maxCalories`, `minProtein` and presets like `high-protein`. They live on the `/recipes` list, which is for a business plan we haven't launched yet. On the free plan you filter in your own code. That last one is easy to work around. Ask search for just the fields you need: ```bash curl 'https://api.tinyplates.dev/search?query=chicken%20curry&limit=20&fields=title,nutrition,servings' \ -H 'Authorization: Bearer rd_your_api_key' ``` Then keep the ones where `nutrition.basis.type` is `serving` and calories are under your limit. Skip the ones with no nutrition rather than treating them as zero. So when is Tiny Plates the right pick? When you want to show recipes with the nutrition their authors published, the way a recipe site does. When is it the wrong pick? When you need every recipe to have numbers, or numbers worked out the same way across all of them. Then use Edamam or Spoonacular to calculate, or build your own on USDA data. ## How accurate is accurate enough? Here's the honest bit. Even lab values are averages. A tomato in July isn't a tomato in January. Labels in the US and the EU are allowed to be off by a fair margin. Recipe calculations stack guesses on top of that. Being within 10 to 20% of the "real" number is normal, and nobody can promise better for a home-cooked meal. For most apps that's fine. A meal planner that says "about 500 kcal" is helping. Someone choosing between a 250 and a 740 kcal curry gets a useful answer either way. Just don't show "487.3 kcal" like it's a fact. Round it. Say "about". Say where it came from. For anything medical, like diabetes, kidney disease or eating disorders, a general API isn't enough on its own. Keep a person in the loop. It's the same thing we say about [allergen data](https://www.tinyplates.dev/blog/allergen-data-for-every-recipe): we tell you what we know, and we tell you what we don't. If showing recipes with their published nutrition fits what you're building, [grab a free Tiny Plates key](https://www.tinyplates.dev/sign-up) and try it. If you need calculated numbers for everything, one of the others above will serve you better. That's fine too.