Nutrition API

People type "nutrition API" and "food API" for the same shopping trip: they need calories and macros for foods their users will log. A food API emphasizes catalog search (names, brands, restaurant items). A nutrition API emphasizes the numbers on those foods (energy, macros, micronutrients when present). Calorie API is both: one REST surface for lookup and for analysis.

A food nutrition API should return a consistent shape whether the hit is a generic food, a branded product, or a barcode fallback. That is what keeps a calorie counter honest when the user switches from "chicken breast" to a UPC on a yogurt cup. The catalog here covers 4M+ foods, with Open Food Facts filling long-tail packaged goods.

If you only need USDA generic foods for research, the free FoodData Central API may be enough. If you are shipping a consumer app, you usually also need typeahead, barcode lookup, branded coverage, and a published quota. Those are the jobs this nutrition API is built for. The USDA guide on the blog is the honest comparison when you have just hit a government rate limit.

A calorie counter API is the backend of a diary: search or scan a food, store the food ID and grams, sum energy for the day. A calorie tracking API is the same loop with history, favorites, and often macros next to calories. Neither requires the API to store your users. You own the logs; the API supplies foods and nutrition.

The practical integration is three endpoints. Debounce GET /api/v1/search/suggest while the user types (id, name, brand). On selection, GET /api/v1/foods/{id} for per-100g macros and serving metadata. For packaged items, GET /api/v1/search/barcode/{upc}. Unknown barcodes return 404 so you can fall back to text search or a custom food.

Quota hygiene matters more than micro-optimizing JSON. Cache food details by ID so re-logging breakfast costs zero extra calls. Debounce suggest. Page search with skip and limit (max 100). Per-account rate limits are safer for mobile fleets behind NAT than IP limits copied from research APIs.

An API for food calories should expose energy as a named field, not as USDA nutrient number 1008 buried in an array. Calorie API returns calories alongside protein_g, carbohydrates_g, and fat_g per 100 g so portion scaling is one multiplication. Micronutrients, when present, arrive in a structured nutrients array.

Calorie estimation is not the same as labeled barcode data. Estimation means you matched a food (or several recipe lines) and scaled a baseline. Photo models estimate from pixels; this nutrition API does not. If you already have ingredient names and grams, resolve each ingredient once, cache the IDs, and aggregate. That pattern is the calorie estimation API most meal-planning backends actually need.

Use verified_only when estimates feed coaching or targets. Manufacturer labels can be incomplete. Verified foods keep the four macros populated so a missing carb field cannot silently under-count a meal.

A barcode food API turns a scanner into a logged item. Pass UPC or EAN digits; separators are stripped. The lookup checks the local catalog first, then Open Food Facts, and returns the same JSON shape either way. If neither source knows the code, you get a clean 404 instead of a fuzzy near-miss.

That last point is the usual failure mode on USDA FoodData Central. Branded FDC records include gtinUpc, but there is no dedicated barcode endpoint. Searching the GTIN as text is fuzzy: you must confirm the returned code matches, after stripping leading zeros, or you will attach the wrong product. A dedicated barcode food API exists so logging apps do not ship that bug.

Commercial grocery and retail apps typically combine barcode lookup with brand filters and allergen fields when the source provides them. Development stays on the free tier; a monetized app needs Plus or Enterprise and the X-API-Usage-Type: commercial header.

Create an account, generate an API key, and send it as X-API-Key. Try search in the playground without signing up. Framework walkthroughs cover React Native food tracking, Next.js apps, Flutter barcode scanning, Node search, and Python analysis. None of those guides require a vendor SDK; the surface is HTTP and JSON.

Start with one user-visible flow. For a tracker, that is suggest plus details. For retail, that is barcode plus a 404 fallback. For analysis, that is verified search plus the nutrients array. Adding every endpoint on day one usually wastes quota on paths you will not ship in v1.

When you compare providers, look at auth, barcode behavior, whether macros are named, rate-limit headers, and commercial terms. The comparison pages cover Nutritionix, Edamam, USDA FoodData Central, Spoonacular, FatSecret, and Open Food Facts with the same hedged claims used in the rest of the site.

FoodData Central is free, authoritative for US generic foods, and the right default for research. A registered api.data.gov key is typically limited to about 1,000 requests per hour per IP. DEMO_KEY is much lower (30 per hour, 50 per day). Exceeding the cap returns HTTP 429 and a one-hour block.

Consumer apps outgrow FDC at two moments: the 429, and the missing barcode-first endpoint. Autocomplete and ranked multi-word search for a logging UI are also on you to build. A commercial nutrition API is that productized layer: named macros, barcode lookup, suggest, dashboards, and a published plan quota. Curated generics in this catalog stay consistent with USDA reference data; verified_only surfaces that tier.

You do not have to pick one forever. A common architecture keeps FDC for citation-grade reference lookups and uses Calorie API on the interactive path. The USDA blog post is written for the developer who just hit the limit and needs the next step, not a bait-and-switch away from the government docs.