How to Scrape Open Beauty Facts Cosmetics Data in 2026

If you need structured cosmetics data — ingredient lists, clean-beauty labels, package sizes, country availability — the usual sources are a mess: retailer pages behind bot walls, PDFs of ingredient decks, or scraping brand sites one at a time. Open Beauty Facts solves the data problem: it’s an open, community-maintained database of 250,000+ personal-care products with a documented JSON API. This guide shows how to pull it in bulk — by category, by brand, or by barcode — without a login or an API key, and where the friction actually is.

What’s worth extracting

Open Beauty Facts returns one row per product with 11 structured fields. Grouped by use:

• Identity — code (the EAN/UPC barcode, your unique key), productName, and brands (comma-separated if the product belongs to a brand group).
• Composition — ingredientsText, the full ingredient list in INCI notation. This is the field most formulators and safety researchers come for; it can run to several hundred characters.
• Claims and safety — labels (certification tags like en:vegan, en:cruelty-free, en:no-parabens) and periodsAfterOpening (the PAO, e.g. 12M for twelve months).
• Classification and availability — categories (the taxonomy path, e.g. “Shampoos, Hair care, Cosmetics”) and countries (comma-separated country tags the product is sold in).
• Packaging and media — quantity (size, e.g. “300 ml”, “50 g”), imageUrl (hosted on openbeautyfacts.org), and the canonical product-page url.

That’s a compact but high-signal schema. For competitive ingredient benchmarking you live in ingredientsText + brands; for clean-beauty research you filter on labels; for catalogue enrichment you join on code.

How the source actually works

The actor talks to the official Open Beauty Facts JSON API (v2) at world.openbeautyfacts.org with a descriptive User-Agent and datacenter proxies. There’s no HTML scraping — this is the same API Open Beauty Facts publishes for developers, running on the same platform as its sibling project Open Food Facts. The API structure between the two is identical.

There are three modes, and picking the right one matters for cost and speed.

Search mode takes one or more categories and optional brand filters, and paginates the API at 100 products per page until it hits your maxResults or exhausts the catalogue:

{
  "mode": "search",
  "categories": ["shampoos", "conditioners"],
  "brands": ["dove"],
  "maxResults": 300,
  "proxyConfiguration": { "useApifyProxy": true }
}

Product mode takes a list of barcodes and fetches each product record individually — one barcode, one row, no pagination overhead:

{
  "mode": "product",
  "barcodes": ["7350160451512", "3600550195132", "4066447909746"],
  "proxyConfiguration": { "useApifyProxy": true }
}

Category mode downloads an entire category tree. Set maxResults to 0 to pull everything in it.

A key detail: Open Beauty Facts uses a taxonomy with specific slugs, not free text. You want face-creams, not “face cream”, and shampoos, not “shampoo”. A misspelled or non-existent category slug returns zero results, not an error — so confirm the slug by browsing the site first.

▶ Open the Open Beauty Facts Scraper on Apify — one run pulls a whole cosmetics category with ingredients, labels, PAO and images. No API key, no login. Export to CSV, JSON, Excel or XML.

The access reality

Open Beauty Facts is an open-data project, so the friction here is about data quality and API limits, not anti-bot defenses:

• The API caps a single search query at 10,000 records. For very large categories (the README notes shampoos alone has 1,700+ items), the actor paginates automatically at 100 per page until it reaches your maxResults or the dataset end. If you need more than 10,000 from one category, split the query.
• No country filter in search mode. The API doesn’t accept a country parameter on search. The pattern is: pull with a high maxResults, then filter the output dataset by the countries field after extraction to build region-specific lists.
• Community data means missing fields. Records are contributed by volunteers, so ingredientsText, labels, or quantity can be null. The row is still pushed with whatever is available — null fields are expected and normal, not a scraper failure.
• Coverage is uneven by region. The database skews strongly toward European brands (French, German, UK markets especially) but spans 180+ countries. If you’re researching a small national market, expect thinner data.

The naive approach — writing your own client against the v2 API — works, but you’ll re-implement pagination, the three lookup shapes, the User-Agent etiquette, and the null-field handling yourself. The actor solves those once.

Example output

One representative product record:

{
  "code": "3600550195132",
  "productName": "Shampoing Expert Force",
  "brands": "Frank Provost",
  "categories": "Shampoos",
  "ingredientsText": "Aqua, Sodium Laureth Sulfate, Cocamidopropyl Betaine, Glycerin, ...",
  "labels": "en:without-parabens",
  "periodsAfterOpening": "24M",
  "countries": "en:switzerland, en:france",
  "quantity": "250 ml",
  "imageUrl": "https://images.openbeautyfacts.org/images/products/360/055/019/5132/front_fr.3.400.jpg",
  "url": "https://world.openbeautyfacts.org/product/3600550195132"
}

The labels and countries fields use tag prefixes (en:) — plan to strip or map those when you display them.

Typical use cases

Who uses this data and for what:

• Cosmetics formulators — competitive ingredient benchmarking across hundreds of SKUs; pull every shampoo from a rival brand and diff the INCI decks.
• E-commerce operators — build or enrich a product catalogue with real ingredient and label data, joining on code.
• Regulatory and clean-beauty researchers — track en:vegan / en:cruelty-free claims or country-specific availability; research PAO data across sunscreens or serums for safety reporting.
• Data scientists — train ingredient-safety models, allergen detectors, or sustainability scorers on the ingredientsText corpus.
• Beauty journalists and bloggers — structured product data for reviews, roundups and infographics without hand-collecting it.
• Launch monitoring — schedule weekly runs in search or category mode and diff the dataset to catch new product launches and updated ingredient lists.

Cost and effort: build vs. managed

Rolling your own client against a public, documented API is the easy end of the scraping spectrum — but “easy” still means writing and maintaining pagination, the three query modes, retry logic, User-Agent etiquette, and null-field normalization, plus scheduling if you want a recurring feed. That’s real hours for data you can get in one click.

The managed actor is pay-per-result: a small per-run start fee plus a fraction of a cent per product record, no subscription, and no API fees (Open Beauty Facts is free). A 200-product run typically completes in under two minutes on datacenter proxy; larger runs scale linearly with pagination. Because you pay per record pushed, a focused category+brand search is cheap, and a full-catalogue category pull is still predictable — cap it with maxResults.

Common pitfalls

Specific to Open Beauty Facts:

• Use exact taxonomy slugs. face-creams, not “face cream”. A wrong slug silently returns zero results. Browse the site to confirm the slug before a big run.
• Null fields are the norm, not an error. Community-contributed data is incomplete. Design your storage and display to tolerate missing ingredientsText, labels or quantity.
• Filter countries after the fact. There’s no country parameter in search; pull broad, then filter on the countries field downstream.
• Barcode mode is the fastest and most exact path. If you already have EAN/UPC codes, product mode skips pagination entirely and returns one clean row per code — use it for catalogue enrichment.
• Long ingredient strings. ingredientsText can be several hundred characters. Size your columns and UI accordingly if you’re loading into a spreadsheet or database.
• Tag prefixes on labels and countries. Both fields carry en: prefixes. Normalize them if you’re presenting the data to humans.
• License terms. Data is published under the Open Database License (ODbL) and is meant for public use, but you’re responsible for complying with the ODbL and the Open Beauty Facts terms when you redistribute it.

Wrapping up

Open Beauty Facts is one of the cleanest cosmetics data sources available — an open API, a rich ingredient-and-label schema, and no bot wall to fight. The engineering is modest: get the taxonomy slugs right, pick the mode that fits (search, barcode, or full category), and handle community-data gaps gracefully. If you’d rather skip building the client and just get the rows, the managed actor does it keyless.

▶ Run the Open Beauty Facts Scraper on Apify — a single run returns an entire cosmetics category or brand with ingredients, labels, PAO, country tags and image URLs. No API key, no login. Export to CSV, JSON, Excel or XML. Start on Apify’s free monthly credit.