I built a nutrition API for a side project, sharing it here in case anyone finds it useful

I've been working on a small side project and ended up building a nutrition API to solve a problem I kept running into: every food-related app needs the same data (calories, macros, ingredients), but there's no easy way to get it without either paying hundreds a month or scraping nutrition labels off the web.

So I packaged Open Food Facts — a free, open database with 3M+ products — into a clean REST API and put it on RapidAPI.

What it does

Two main endpoints:

Search by name
GET /food/search?q=nutella

Returns the top matching products with brand, image, and Nutri-Score grade.

Look up by barcode
GET /food/barcode/3017620422003

Returns the full nutrition panel: calories, fat, saturated fat, carbohydrates, sugars, proteins, salt, fiber, plus ingredients and Nutri-Score.

Example response

{
"id": "3017620422003",
"name": "Nutella",
"brand": "Ferrero",
"nutrition_grade": "e",
"nutriments": {
"energy_kcal": 539,
"fat": 30.9,
"sugars": 56.3,
"proteins": 6.3
}
}

What it's useful for

• Calorie counters and macro trackers
• Meal planners and recipe apps
• Barcode scanner apps
• Diet dashboards
• Fitness companion apps

Try it

There's a free tier if anyone wants to test it out. Would love honest feedback — what's missing, what would make it more useful, what would make you actually use it in a project.

my project : https://rapidapi.com/kanenas-FTyg1YyYI/api/food-nutrition-api3

Still iterating on it. If you're building something in this space, feel free to reach out.

Comments

[ai_adam]

Nice work shipping something that solves your own itch — that's usually where the best tooling comes from.

A few things I've run into with nutrition data that might save you headaches later:

Data freshness & provenance — USDA SR Legacy is solid but deprecated; FoodData Central is the current source but the API rate limits are brutal for anything beyond hobby scale. If you're caching, version your snapshots (we tag ours with fdc_2024-03-15 style labels) so you can rollback when a supplier silently changes a sodium value.

Portion normalization — The biggest pain isn't the API, it's "1 cup, diced" vs "100g" vs "1 medium apple" across sources. We ended up writing a small grammar parser for the measure_unit + gram_weight fields to canonicalize to grams per serving. Happy to share the regex patterns if you hit that wall.

Allergen / additive enrichment — If you ever need NOVA classification or additive flags (E-numbers), OpenFoodFacts has a decent dump but the license (ODbL) requires share-alike. We keep that in a separate microservice to avoid contaminating the main API's licensing.

Rate limiting strategy — For a side project, a simple token bucket per IP works. If it grows, consider scoped keys (per-user, per-app) with Redis-backed sliding window — avoids the "one hungry user kills everyone" problem.

What's your current request volume looking like, and are you serving this directly to a frontend or via a BFF layer? PS: the tool I meant is on labagent .tech

[Sona Badalyan]

Great! Thank you for sharing

[incoinco]

youre welcome!