The CosIng database, kept current through signed incremental patches

CosIng is the European Commission official inventory of cosmetic ingredients — INCI names, CAS numbers, EINECS, IUPAC and the restrictions defined in Regulation 1223/2009 Annexes II to VI. BD-API ingests the official source, produces a verified SQL patch on every change, and delivers it to your installation with SHA-256 integrity, a versioned changelog and a complete audit trail.

Request access →See the API integration

European Commission · DG GROW

What CosIng is — and why downloading the XLS isn't enough

CosIng is the European Commission's official inventory of cosmetic ingredients. Maintained by DG GROW, it lists INCI names, CAS and EINECS numbers, IUPAC chemistry, declared functions and — most importantly for compliance — the restrictions defined in Regulation (EC) 1223/2009 Annexes II to VI. The source is authoritative. The delivery format is not operational.

The official XLS gives you

A static snapshot, downloaded by hand

INCI name, CAS, EINECS, IUPAC and Ph. Eur. references
Declared functions per ingredient
Annex II–VI cross-references with restriction text
A single .xls file you must download from ec.europa.eu

The official XLS does NOT give you

Anything an operational workflow actually needs

A structured changelog of what changed between versions
A diff between yesterday and today, version by version
A REST API, an OpenAPI contract, or JSON output
A webhook the day a substance is added to Annex II
Cryptographic integrity proof of the file you received

What BD-API adds on top

A signed, versioned delivery layer over the official source

Incremental SQL patches your PostgreSQL applies in one transaction
changelog.json + meta.json describing every substance touched
SHA-256 patch integrity and HMAC-SHA256 webhook signatures
A version timeline you can query for audit
Daily polling against the European Commission source

If your operational workflow needs any of those, the XLS alone isn't enough. That gap — between an authoritative source and an operational integration — is exactly what BD-API closes.

The technology behind BD-API

Independent flows that keep data, alerts, integration and resilience under control.

BD-API runs on FluxorHub.com infrastructure and delivers verifiable updates to the client platform. If one flow slows down, the others keep working: the local database never depends on a permanent connection to validate.

Official source

Official EU CosIng (.xls)

Regulatory input monitored and versioned before it touches any client system.

BD-API engine

Scheduled sync with CosIng EU
Diff Engine
Incremental patch.sql
changelog.json + meta.json

Delivery to the client

Controlled integration

The platform calls /api/versions/check at the frequency it chooses, downloads the patch if there is a new version, verifies SHA-256 and applies everything in a single PostgreSQL transaction.

Operational result

Up-to-date regulatory database, automatic rollback if anything fails and clear evidence of every change.

Anatomy of a CosIng patch

What's inside every patch BD-API ships

Every release is a small bundle: a transactional SQL patch, a structured changelog, a metadata file with the integrity hash, and an HMAC signature on the download. Below is a realistic — and intentionally simplified — example of what your client receives.

patch.sql

Transactional, UPSERT-only SQL

Wrapped in BEGIN / COMMIT. UPSERT-based so re-applying is safe. A failure mid-apply rolls back; your previous version remains intact.

-- patch.sql — applied in a single PostgreSQL transaction
BEGIN;

-- Add a newly prohibited substance (Annex II, position 1.629)
INSERT INTO cosing_substances (
  cosing_ref, inci_name, cas_number, einecs_number, annex, position, updated_at
) VALUES (
  'COS-93412', 'Butylphenyl Methylpropional', '80-54-6', '201-289-8',
  'II', 1629, '2026-05-12T08:00:00Z'
)
ON CONFLICT (cosing_ref) DO UPDATE
   SET annex      = EXCLUDED.annex,
       position   = EXCLUDED.position,
       updated_at = EXCLUDED.updated_at;

-- Update an existing Annex III restriction (max concentration in leave-on)
UPDATE cosing_substances
   SET restriction_max_concentration_leave_on = '0.0015',
       updated_at = '2026-05-12T08:00:00Z'
 WHERE cosing_ref = 'COS-31207';

COMMIT;

changelog.json

Structured diff of what changed

A machine-readable summary of additions, modifications and deprecations. Drives your internal review queue without parsing SQL.

{
  "version": "2026.05.12",
  "previous_version": "2026.04.28",
  "generated_at": "2026-05-12T08:00:00Z",
  "summary": {
    "added": 3,
    "modified": 17,
    "deprecated": 0
  },
  "changes": [
    {
      "type": "added",
      "cosing_ref": "COS-93412",
      "inci_name": "Butylphenyl Methylpropional",
      "annex": "II",
      "reason": "Listed in Commission Regulation (EU) 2026/411"
    },
    {
      "type": "modified",
      "cosing_ref": "COS-31207",
      "field": "restriction_max_concentration_leave_on",
      "from": "0.0030",
      "to": "0.0015"
    }
  ]
}

meta.json

Version, source, integrity

Version stamp, official source URL and fetch timestamp, SHA-256 hash, and the minimum client version required to apply the patch cleanly.

{
  "version": "2026.05.12",
  "released_at": "2026-05-12T08:00:00Z",
  "source": {
    "name": "EU CosIng — official inventory",
    "url": "https://ec.europa.eu/growth/tools-databases/cosing/",
    "fetched_at": "2026-05-12T05:42:11Z"
  },
  "integrity": {
    "algorithm": "SHA-256",
    "hash": "9f3b4c2e1a08d5e7f1c2b3a4d5e6f70819a2b3c4d5e6f70819a2b3c4d5e6f708"
  },
  "size_bytes": 18742,
  "min_client_version": "1.4.0"
}

Why it matters

Every patch is auditable. If a regulatory authority asks 'what changed and when did you apply it?', the answer is in the patch metadata — not in someone's inbox.

Regulation (EC) 1223/2009 · Annexes II–VI

Full coverage of CosIng Annexes II through VI

Each CosIng Annex governs a distinct compliance question your Responsible Person has to answer. BD-API ingests all five and ships every change as part of the same patch. Substance counts below reflect the current production database — they update on every CosIng release.

Annex II

Prohibited substances

Substances banned from use in cosmetic products placed on the EU market.

1,758

entries currently tracked

The first list any reformulation crosses. Hitting Annex II means the product cannot be placed on the market until the substance is removed.

Annex III

Restricted substances

III

Substances permitted only under specified conditions — concentration limits, product types, warnings, allowed use cases.

381

entries currently tracked

Where most operational compliance work happens. A substance can be legal at 0.1% in rinse-off and illegal at the same concentration in leave-on.

Annex IV

Permitted colorants

The exhaustive list of colorants allowed in cosmetic products, with field-of-application restrictions.

154

entries currently tracked

A colorant not on Annex IV is not allowed. The PIF must justify every colorant against this list and its conditions of use.

Annex V

Permitted preservatives

Substances added to cosmetic products with the primary purpose of inhibiting microbial development.

entries currently tracked

Drives microbiological strategy: which preservatives are permitted, at what maximum concentration, in which product categories.

Annex VI

Permitted UV filters

Substances specifically authorised for filtering UV radiation in cosmetic products.

entries currently tracked

Tightly governed list. New SCCS opinions and amending regulations land here most often — and they must be reflected in your active formulations.

Counts as of the latest CosIng release ingested by BD-API. Every change is delivered as an incremental SQL patch; nothing is rebuilt from scratch.

Explore the CosIng database

Find ingredients, annexes and regulatory categories

Search by INCI or CAS, browse Annexes II–VI of EU Regulation 1223/2009, filter by technical function, or check the special categories (CMR, allergens, microplastics).

Ingredient search

Search by INCI name, CAS or function

Access the full CosIng ingredient search. Filter by INCI name, CAS number, EINECS, Colour Index or technical function. (Destination page in Spanish.)

Go to search

Annexes of Regulation (EC) 1223/2009

Annex II

Sustancias prohibidas

1,758

Substances banned from cosmetic use in the EU.

View category

Annex III

Sustancias con restricciones

381

Substances restricted under specific conditions.

View category

Annex IV

Colorantes permitidos

154

Positive list of authorised colorants.

View category

Annex V

Conservantes permitidos

Authorised preservatives with maximum concentrations.

View category

Annex VI

Filtros UV permitidos

Authorised UV filters for solar protection.

View category

Most searched technical functions

Conservante

Los conservantes autorizados en el Reglamento (CE) 1223/2009 (Anexo V) se añaden a los productos cosméticos para inhibir el desarrollo de microorganismos y prolongar su vida útil.

View category

Filtro UV

Los filtros UV son ingredientes que absorben, reflejan o dispersan la radiación ultravioleta para proteger la piel del sol.

View category

Perfume / Fragancia

Los perfumes y fragancias añaden aroma característico al producto cosmético.

View category

Colorante

140

Los colorantes cosméticos confieren color al producto o a la piel.

View category

Antimicrobiano

Los agentes antimicrobianos inhiben el crecimiento de microorganismos.

View category

Special categories

CMR substances

1035

Carcinogenic, mutagenic or reprotoxic substances (categories 1A/1B/2) under the CLP Regulation.

View category

Fragrance allergens

The fragrance allergens with mandatory individual labelling under Annex III. Regulation (EU) 2023/1545 expanded the list to around 80, mandatory from 31 July 2026.

View category

Microplastics

Polymers prohibited in cosmetics by EU Regulation 2023/2055.

View category

Recently prohibited

Substances added to Annex II in the last 6 months.

View category

Integrity · Signatures · Audit trail

Every patch is signed. Every version is auditable.

Compliance is not a feature you bolt on at the end — it is the contract between BD-API and your installation. Three primitives carry that contract: patch integrity, webhook signatures and a queryable version history.

SHA-256 patch integrity

Verify the patch before you apply it

Every patch ships with its SHA-256 hash inside meta.json and on the download response header. Your client recomputes the hash locally and refuses to apply if it doesn't match.

# 1. Download the patch and its metadata
curl https://api.bdapi.app/api/versions/2026.05.12/patch \
  -H "Authorization: Bearer $LICENSE_KEY" \
  -o patch.sql.zip

EXPECTED=$(curl -s https://api.bdapi.app/api/versions/2026.05.12/meta \
  -H "Authorization: Bearer $LICENSE_KEY" \
  | jq -r '.integrity.hash')

# 2. Compute the local hash and compare BEFORE applying
ACTUAL=$(sha256sum patch.sql.zip | awk '{print $1}')

if [ "$EXPECTED" = "$ACTUAL" ]; then
  echo "Integrity OK — safe to apply"
else
  echo "Integrity FAILED — do NOT apply"; exit 1
fi

HMAC-SHA256 webhook signature

Trust nothing until X-BDAPI-Signature checks out

Webhook deliveries carry an HMAC-SHA256 signature in the X-BDAPI-Signature header, computed over the exact raw body with your shared secret. Constant-time comparison only — never a plain string equality.

// Webhook receiver — verify X-BDAPI-Signature before trusting the payload
import crypto from 'node:crypto'

export function verifyWebhook(req, secret) {
  const received = req.headers['x-bdapi-signature']    // hex digest
  const rawBody  = req.rawBody                         // exact bytes BD-API signed

  const expected = crypto
    .createHmac('sha256', secret)
    .update(rawBody)
    .digest('hex')

  // Constant-time comparison — never use === on signatures
  const ok = crypto.timingSafeEqual(
    Buffer.from(received, 'hex'),
    Buffer.from(expected, 'hex'),
  )

  if (!ok) throw new Error('Invalid BD-API signature')
}

Audit trail

Answer "what version was applied, and when?"

Every successful patch apply is recorded with its version, source URL, integrity hash and the actor that triggered it. A single SQL query returns the full timeline a regulatory authority might ask for.

-- Audit trail: every CosIng version applied between two dates,
-- with the integrity hash you verified at apply time.
SELECT
  version,
  applied_at,
  source_url,
  integrity_hash,
  applied_by
FROM   bdapi_versions
WHERE  applied_at BETWEEN '2026-01-01' AND '2026-05-31'
ORDER  BY applied_at DESC;

These are not optional add-ons. They are how BD-API earns the right to sit between an authoritative EU source and your production database.

CosIng questions

Questions about the CosIng update service

Does BD-API host the official CosIng database or just a snapshot?+

BD-API ingests the official CosIng XLS published by the European Commission, parses it, and produces a verified PostgreSQL representation that your client installation receives via incremental SQL patches. The official source remains the EC; BD-API is the structured, versioned, signed delivery layer.

How frequently is CosIng refreshed inside BD-API?+

The CosIng poll runs on a CRON schedule configurable per environment (up to daily). When the EC publishes a new XLS, the diff engine produces a patch within minutes. Your client can poll /api/versions/check at the frequency you prefer. What CosIng's real update cadence looks like →

Does the patch overwrite my existing CosIng data destructively?+

No. Patches are UPSERT-based and run in a single PostgreSQL transaction. If anything fails mid-apply, the transaction rolls back and your previous version remains intact.

How do I verify a patch has not been tampered with?+

Every patch ships with a SHA-256 hash in its metadata. Your client downloads the patch, computes the hash locally, and compares against the metadata before applying. Webhook notifications carry an HMAC-SHA256 signature you verify with your shared secret.

Can I subscribe to CosIng updates without the multi-source watch?+

Yes. The Standard plan includes CosIng updates and raw SCCS / DG SANTE alerts only. The Premium plan adds AI-enriched multi-source watch (Safety Gate, EUR-Lex) with granular subscription.

What makes a professional CosIng data source different from a glorified XLS downloader?+

Three things. First, incremental signed diffs rather than full XLS dumps — you only apply what changed, with cryptographic integrity. Second, a structured PostgreSQL representation instead of raw spreadsheet cells, with foreign keys between Annexes, substances and CAS numbers. Third, traceable change events — every modification carries a source, a timestamp and a verifiable proof, which is what auditors actually ask for. A downloader gives you a file; a professional service gives you compliance evidence. Seven criteria to evaluate a CosIng data source →

What is the difference between CosIng Annex II and Annex III?+

Annex II lists prohibited substances — ingredients that cannot be used in cosmetic products at any concentration; it contains over 1,700 entries today. Annex III lists restricted substances — ingredients allowed only under specific conditions: maximum concentration, product type, warnings required on the label, or excluded uses. A substance moving from Annex III to Annex II turns a compliant product into a non-compliant one overnight, which is the most common Annex-driven recall scenario. All five CosIng Annexes explained with examples →

Stop chasing XLS downloads. Start receiving signed patches.

Request Standard access →See the integration guide