Open Food Facts

Implementation notes

When to use Open Food Facts

Open Food Facts is a nonprofit, crowd-sourced database of over three million food products keyed by barcode, with ingredient lists, allergens, nutrition facts per 100g, Nutri-Score and NOVA classifications, packaging data, and product photography. It is the only free, open, globally scoped barcode-to-food-data source that exists — the commercial alternatives all meter you per call and none of them let you download the whole dataset. Use it for barcode-scanning apps, diet trackers, allergen checkers, and sustainability tooling. It runs on donated infrastructure under an ODbL licence, which means the data really is yours to use including commercially, provided you share back derived databases. Expect wiki-grade data quality: excellent for products people care about, thin or entirely absent for the rest, and never uniformly complete across the specific fields your UI wants. Design for missing data first and the integration is straightforward.

Common pitfalls

• An identifying User-Agent is mandatory. The required form is application name, version, and a contact URL or email — for example MyDietApp/1.2 ([email protected]). Default client user agents are blocked, and the block sits at the CDN, so you get a generic error page rather than an API response telling you what went wrong.
• Every field is optional in practice. A record can have a barcode and a name and nothing else; nutriments can be an empty object; energy may be present in kJ but not kcal; ingredients_text may exist in French but not English. Null-check everything you render, and never compute a total from fields you did not verify — a tracker that treats missing sugars as zero is worse than one that says unknown.
• For a barcode you already have, call /api/v2/product/{barcode}.json directly — it is a single indexed lookup and returns quickly. The search endpoint is a different beast: slow under load, paginated, and easy to hammer accidentally. If you need the whole dataset, take the published dump rather than paging search, which is what will actually get you blocked.
• Product images live on images.openfoodfacts.org, a separate host, at paths derived from splitting the barcode into groups rather than a URL you can reliably construct. Use the image_url, image_front_url, and image_ingredients_url fields from the product response instead of building paths yourself, and expect them missing on a large share of products.

Quick start (bash)

curl -s -H 'User-Agent: MyDietApp/1.0 ([email protected])' 'https://world.openfoodfacts.org/api/v2/product/3017620422003.json' | jq '.product.product_name, .product.nutriments.sugars_100g, .product.image_front_url'
# null is a completely normal answer for any nutriment field - guard every read

Embed this badge

Add a live status badge to your README, docs, or website.

Markdown

[![Open Food Facts Status](https://api.freeapi.watch/badge/open-food-facts.svg)](https://freeapi.watch/open-food-facts)

HTML

<a href="https://freeapi.watch/open-food-facts"><img src="https://api.freeapi.watch/badge/open-food-facts.svg" alt="Open Food Facts Status"/></a>