Executive Summary: The Open Beauty Facts API is a free, crowdsourced, barcode-first database of cosmetics under an open (ODbL) licence. The Beauty API is a commercial, normalized dataset and REST API covering 180,000+ skincare and cosmetics products and 22,000+ ingredients with INCI mapping, irritancy and comedogenicity ratings, and a standardized image archive. Open Beauty Facts is the right call for hobby projects, barcode lookups and anything that can live with share-alike licensing. The Beauty API is the right call when you need clean ingredient data on day one and want to keep your own database proprietary.

If you are building a skincare app, an ingredient checker or a cosmetics storefront, the first infrastructure decision is where the product catalogue comes from. Two of the options developers compare most often are the Open Beauty Facts API and The Beauty API. They solve overlapping problems in very different ways, so this comparison looks at what each actually returns, what it costs, what the licence allows, and which one fits which project. We build The Beauty API, so read the verdict with that in mind; the facts in the table are checkable against both sets of docs.

What is the Open Beauty Facts API?

Open Beauty Facts is the cosmetics sibling of Open Food Facts: a volunteer-run, Wikipedia-style database where anyone can scan a product's barcode, upload photos of the packaging and type in the ingredients. The API is free, needs no key, and is organised around barcodes. A product lookup is a single GET:

curl "https://world.openbeautyfacts.org/api/v2/product/3600523281176"

// Trimmed response
{
  "status": 1,
  "product": {
    "code": "3600523281176",
    "product_name": "...",
    "brands": "...",
    "ingredients_text": "Aqua, Glycerin, ...",
    "ingredients": [{ "id": "en:water", "text": "Aqua" }, ...],
    "image_front_url": "https://images.openbeautyfacts.org/...jpg",
    "image_ingredients_url": "https://images.openbeautyfacts.org/...jpg"
  }
}

What you get is what contributors uploaded: the barcode, a product name and brand, one or more photos of the physical packaging, the ingredient text as typed, and a machine-parsed ingredients array derived from that text. The full database is also downloadable as a bulk export. The project asks API users to rate-limit themselves and cache responses, because it runs on donated infrastructure.

What is The Beauty API?

The Beauty API is a commercial dataset and hosted REST API built for production skincare and beauty applications. Every product record carries its full ingredient list in on-label order, with each ingredient resolved to a canonical INCI name and joined to a scientific record: functions, rating, irritancy and comedogenicity scores, CAS and EC numbers, and synonyms. Five free-from flags (fragrance, drying alcohol, parabens, sulfates, silicones) are precomputed on every product, and each product has a standardized white-background photo. The same data is available as a one-time dataset licence (CSV, JSONL, SQLite plus the 18GB image archive) and through the API:

curl "https://api.thebeautyapi.com/v1/products/search?q=niacinamide" \
  -H "x-api-key: YOUR_API_KEY"

// Then fetch the full record
curl "https://api.thebeautyapi.com/v1/products/06d9476a-397b-5f61-abc8-640b30a9ae23" \
  -H "x-api-key: YOUR_API_KEY"

// Trimmed response
{
  "brand": "The Ordinary",
  "name": "Niacinamide 10% + Zinc 1%",
  "image_url": "https://images.thebeautyapi.com/06d9476a-....jpg",
  "contains_fragrance": false,
  "contains_drying_alcohol": false,
  "ingredients": [
    {
      "position": 1,
      "name": "Niacinamide",
      "concentration": 10.0,
      "rating": "direct actives",
      "irritancy": null,
      "comedogenicity": null,
      "functions": ["smoothing"],
      "cas_number": "98-92-0"
    }
  ]
}

Search is by brand and name, discovery filters by category, brand, origin, free-from flags and ingredient, and barcode-enabled plans resolve a scanned UPC or EAN to the same record. A free Sandbox plan (100 calls a month) covers evaluation and prototypes. The full endpoint list is in the API documentation.

Open Beauty Facts API vs The Beauty API: side by side

Feature Open Beauty Facts API The Beauty API
Cost Free, no key required Free Sandbox (100 calls/month); paid API plans; one-time dataset licence
How data is collected Crowdsourced: volunteers scan and type Collected and normalized by a single pipeline, released in versioned snapshots
Catalogue coverage Depends on what contributors have scanned; strong for mass-market European products, patchy elsewhere 180,000+ skincare and cosmetics products across global brands
Ingredient list Free text as typed, plus a parsed array derived from it; quality varies per entry Structured array in on-label order, every ingredient resolved to a canonical INCI record
Ingredient safety data Not provided Irritancy and comedogenicity scores, functional classes, rating, CAS/EC identifiers
Free-from flags Derived by you from the text Precomputed: fragrance, drying alcohol, parabens, sulfates, silicones
Images User photos of packaging, any angle and background One standardized white-background image per product, 18GB archive
Barcode lookup Yes, the primary key Yes, on barcode-enabled plans
Schema stability Fields can be missing or inconsistent between products Fixed schema, documented in OpenAPI, same fields on every record
Licence ODbL (attribution and share-alike) for data; photos under Creative Commons Commercial licence; your derived database stays yours
Best for Hobby projects, research, barcode scanners, open-data apps Production apps, e-commerce, recommenders, model training

Where Open Beauty Facts wins

  • It is free and open. No key, no invoice, and you can download the whole database. For a student project or a hackathon there is nothing to sign.
  • Barcodes are first-class. Because contributors start by scanning, almost every entry has a GTIN. If your app is "scan a bottle, show me something", the free lookup is hard to beat on price.
  • Community reach. Volunteers add obscure, regional and indie products that no curated catalogue prioritises, and you can add products yourself.

Where The Beauty API wins

  • The ingredient data is usable without a cleaning step. Names are canonical, order is the label order, and the safety scores your recommendation or conflict logic needs are already on the record. With crowdsourced text you write the parser, the synonym table and the scoring layer yourself, and maintain them as entries change.
  • Every record has the same shape. A fixed schema means no defensive if (product.ingredients_text) code paths and no surprises in production.
  • Images are consistent. One product, one standardized photo, suitable for a catalogue grid or a training set, instead of whatever angle a contributor photographed under kitchen lighting.
  • You keep your database. This is the point most teams miss until legal review, so it gets its own section.

The licensing catch: what ODbL share-alike means for a commercial app

Open Beauty Facts data is released under the Open Database License. Commercial use is allowed, with two conditions: you must attribute the source, and if you build a derived database and make it publicly available you must release that derived database under the same ODbL terms. For a personal app that is a non-issue. For a startup whose enriched product catalogue is the product, it means the improvements you layer on top of the open data can be subject to share-alike obligations. Read the licence with counsel before you ship. The Beauty API is a conventional commercial licence: the data you derive from it stays yours.

Which should you choose?

  • Weekend project, coursework, or an open-source app: Open Beauty Facts. Contribute back the products you scan.
  • Barcode scanner on a zero budget: Open Beauty Facts for the lookup, with the expectation that ingredient text will need cleaning before you can reason about it.
  • Skincare recommender, ingredient checker or routine builder: The Beauty API. The safety ratings and label-order ingredient arrays are what the recommendation logic runs on; our guide to building a skincare recommender app with the API walks through the five endpoints involved.
  • E-commerce catalogue or product matching: The Beauty API for its consistent schema and imagery; add a barcode-enabled plan if you ingest scanned codes.
  • Training a model: The Beauty API dataset licence, which delivers the full catalogue as CSV, JSONL and SQLite with the image archive.
  • Not sure yet: download the free 1,000-product sample, which has the same fields as the full dataset, and compare it against an Open Beauty Facts export on the products you care about.

Frequently asked questions

Is the Open Beauty Facts API free?

Yes. There is no API key and no charge. The project asks developers to identify their app in the User-Agent header, cache responses, and keep request rates modest.

Does Open Beauty Facts have ingredient data for cosmetics?

Yes, where a contributor has typed or photographed the ingredient list. You get the text as entered and a parsed array derived from it. It does not include irritancy, comedogenicity or functional classifications, and naming follows whatever the contributor typed.

Can I use Open Beauty Facts data in a commercial app?

Yes, under ODbL: attribute the source, and share any publicly available derived database under the same licence. See the licensing section above.

Does The Beauty API have a free tier?

Yes. The Sandbox plan gives 100 API calls a month at no charge for evaluation, and the 1,000-product sample is a free download. See the FAQ for plan details.

Does The Beauty API support barcode lookup?

Yes, on barcode-enabled plans, via GET /v1/products/barcode/{barcode}. UPC-A, EAN-13 and GTIN-8/14 forms of the same code all resolve to the same product.

The verdict

These two are not really competitors; they sit at different points on the effort-versus-cost curve. Open Beauty Facts is an excellent free, open, barcode-first resource, and the right default for learning and for open-data projects. The Beauty API is the shorter path when the ingredient data has to be correct and structured before your first user signs up, and when your catalogue needs to remain your own. If engineering time is your scarcest resource, paying for normalized data is usually cheaper than building and maintaining the normalization yourself.