CosIng API vs manual XLS downloads: an honest comparison

• The official CosIng .xls is free and official — and it hands you a full snapshot with no diff, no hash, and no schema guarantee, every single time.
• The real comparison is not price. It is who owns the update pipeline: your team, or a service whose whole job is that pipeline.
• There are cases where the spreadsheet is genuinely the right call — they are listed below, honestly.

1. Two ways to consume the same data

The CosIng database is the European Commission's official inventory of cosmetic ingredients and their restrictions under Regulation 1223/2009. Everyone consuming CosIng data programmatically starts from the same fork:

1. Manual route — download the official .xls from ec.europa.eu, parse it, load it into your system, repeat on every update.
2. API route — consume a CosIng database API that ingests the official source and delivers structured, versioned data over HTTP and SQL.

The first route looks free. The second looks like a dependency. Both impressions deserve scrutiny.

2. What the manual workflow actually involves

Downloading the file is the easy 5%. A production-grade manual pipeline needs:

• Change detection. CosIng does not announce a fixed release schedule — updates land when amending regulations land. Someone (or some cron job) has to notice.
• Diffing. The XLS is the full current state, not a changelog. To know what changed — the only thing your compliance team actually cares about — you diff thousands of rows against your previous snapshot.
• Parsing resilience. Spreadsheet columns are not a versioned schema; they can shift between releases, and your parser finds out at 2 a.m.
• Integrity. The file carries no hash and no signature. If the download truncates or someone edits the intermediate file, nothing tells you.
• An owner. Every step above is a process someone must own, document, and hand over when they leave. That person is rarely hired for it.

None of this is exotic engineering. All of it is undifferentiated engineering — work that makes your product no better than competitors, done identically by every team that picks this route.

3. What the API route changes

A professional API moves that pipeline server-side and gives you two consumption models, matched to two different needs:

For lookups, prototypes and tooling — public REST endpoints, no API key: search by INCI or CAS, browse Annexes, list CMR substances, query what was recently added to Annex II. If you want to see them working, the hands-on guide to querying the CosIng database programmatically runs every endpoint with real captured responses.

For production compliance software — signed incremental SQL patches into your own PostgreSQL: you receive only what changed, verify the SHA-256 hash before applying, and your product validates ingredients offline with no per-request dependency on anyone — including the API provider.

The second model is the structural difference. It is not "the XLS, but hosted": it is a change-delivery contract with integrity guarantees, which is what auditors and Responsible Persons actually ask about.

4. Side by side

5. When the XLS is genuinely enough

Honesty over pitch — the manual route is the right call when:

• A human consults the data occasionally. A regulatory specialist checking a dozen ingredients during a reformulation does not need an API. The official portal and the spreadsheet serve that perfectly.
• The data feeds a one-off analysis. A market study, an academic project, a due-diligence snapshot: download, analyse, done. No pipeline needed because there is no ongoing need.
• Nothing downstream depends on freshness. If being three months stale has no consequence, the cost of staleness is zero and so is the case for automation.

The line is crossed the moment software depends on the data being current. Then staleness becomes a compliance risk with a date on it, and the seven questions in how to choose a CosIng data source become the evaluation that matters.

6. The migration path is not all-or-nothing

Teams rarely jump from spreadsheet to full sync in one step, and they should not have to:

1. Prototype against the public endpoints — validate that structured CosIng data improves your product. No key, no contract, an afternoon of work.
2. Wire compliance checks into your staging environment — still on public endpoints, respecting the documented rate limits.
3. Move production to the licensed sync — your own PostgreSQL replica, signed patches, offline validation.

Each step is independently reversible, which is exactly what you want from an infrastructure decision.