How to choose a CosIng data source: seven criteria that separate a professional service from a glorified downloader

• The official CosIng portal gives you a .xls you download manually and diff against your previous version. That does not scale.
• Evaluating a CosIng API or any cosmetic regulatory database alternative requires seven concrete criteria, not just a price comparison.
• If your current provider cannot answer three of four specific questions with verifiable evidence, you have a problem worth fixing now.

1. Why the source matters

The European Commission's CosIng database is public, free, and official. It also arrives as a .xls file you download manually, compare line by line against your previous snapshot, and transform before your system can consume it. If your active portfolio has ten ingredients, that is an afternoon's work each time an update drops. Fifty ingredients and it becomes a coordinated process someone has to own, document, and review. A hundred or more and it needs engineering.

The operational reality is this: CosIng does not give you changes — it gives you the full current state. The difference between a data downloader and a professional source is exactly that distinction: one delivers a dump every time, the other delivers only what changed, signed, with a traceable chain back to the official publication. That is not a technical nuance or a marketing differentiator. It is the line between something that scales and something that does not.

Before committing to any CosIng data source, CosIng API provider, or cosmetic regulatory software option, here are the seven criteria to evaluate objectively.

2. The seven criteria to evaluate

2.1. Dataset freshness: how often does it actually update?

The European Commission publishes CosIng updates periodically, but not on a fixed, easy-to-track cycle. A professional service should reflect those updates within a reasonable window after official publication — not weeks later.

The relevant question is not "how fast do you say you update?" It is: "when was the last real update in your system and what changed?" If they cannot answer that with a date and a verifiable changelog, the declared cadence is marketing copy.

A useful follow-up: does the provider publish an update history? Is there a feed or endpoint that tells you when the dataset was last touched? If neither exists, you are operating blind on freshness.

2.2. Incremental diffs vs. full dumps

This is the criterion with the highest long-term impact on your pipeline. A service that only delivers the full dataset every time means you carry the diff logic on your side: download everything, compare against your previous snapshot, identify what is new, validate deletions. That is work that should not be yours.

A well-designed service delivers exclusively what changed since a date you specify. The question to ask is direct: "what endpoint do you give me to get changes since date X?" If the answer is a link to a downloadable Excel file, you already have your answer.

Incremental diffs are not just a convenience feature. They are the foundation for making data processing deterministic, auditable, and efficient regardless of how large your portfolio grows.

2.3. Structured format vs. PDF or XLS

The delivery format determines how much work stays on your side. An Excel file requires a parser, typing decisions, encoding management, and structural change handling every time the Commission adds or renames a column. A PDF is not viable for automated integration by any reasonable definition.

A structured format — typed JSON with unambiguous fields — connects directly to your pipeline: database ingestion, ETL, schema validation. Two questions to ask: "is the response schema documented?" and "is there an OpenAPI spec or equivalent?" If the schema is not documented, the integration contract changes whenever the provider decides it does, without notice.

An additional signal: does the provider version their API? An unversioned API is an integration risk — any change can break your consumer silently.

2.4. Source authority and traceability

This is the easiest criterion to overlook and the most critical in a regulatory context. The question is simple: "how do I know that the data you give me is what the Commission actually published?"

A service that scrapes the official portal without traceability adds a layer of uncertainty that cosmetic compliance cannot afford. If tomorrow there is a discrepancy between what your system says and what the Official Journal of the EU (OJEU) shows, you need to trace the origin of every record exactly.

What you are looking for in a serious provider: they can tell you the precise source of each record (URL or publication reference), the timestamp when the system captured that change, and any transformation applied. No audit trail means no traceability. Without traceability, in a regulatory inspection you are relying on the provider's good faith.

2.5. Active delivery (webhook) vs. passive pull

If the integration requires your system to go and fetch data on a schedule — polling — you are paying twice: in operational infrastructure cost, and in latency. Polling also introduces uncertainty windows: is the data I read three hours ago still current?

A service with active delivery inverts the equation: when there is a change, the provider notifies you. The question to ask is: "does the system tell me when something changes, or do I go and check?"

A properly implemented webhook has an important consequence that leads directly to the next criterion: payload signing.

2.6. Authentication and payload signing

An unsigned webhook is an open channel. Anything can POST to your endpoint, and without validation your system will process data of unknown origin as if it were legitimate regulatory data. In a context where that data feeds compliance decisions, that is a concrete risk vector.

The question to ask: "how does the system sign its webhooks and how do I verify them?" The expected answer involves a specific signing mechanism — HMAC-SHA256 is the standard — with a secret key you control. If you have worked with signed webhooks before, the verification pattern is well-understood. If not, we have covered it in detail: how to verify HMAC signatures on BD-API webhooks.

Without signing, there is no way to trust the integrity of the payload. Without integrity, active delivery loses most of its value.

2.7. Active regulatory support vs. data delivery only

CosIng is not a static dataset. Regulation 1223/2009 has been amended dozens of times since it was published. Each amending Commission Regulation can add entries, modify restrictions, or change the structure of the Annexes. When that happens, a provider that only delivers data has a problem: the schema they documented no longer matches reality.

The question to ask: "what does your system do when the Commission adds a new field to CosIng?" The expected answer includes a schema update process, proactive communication to clients, and a track record of how previous structural changes were handled.

Layer on top the analysis question: does the provider enrich the data with regulatory context — which Annex is affected, what changed versus the previous version, what the practical impact is for your portfolio — or do they hand you the raw record and stop there? The distance between raw data and interpreted data is the distance between information and a decision you can act on.

3. The ten-minute pre-commitment test

Before committing to any CosIng API or cosmetic regulatory database alternative, ask these four concrete questions and demand verifiable answers — not marketing positioning:

1. "When was your last dataset update and what changed?" — Expect a date and a changelog or change list. A vague answer means real cadence is unknown.

2. "How do I get only the changes since a specific date?" — Expect a documented endpoint with a date parameter. If the answer is to download the full dataset, the diff is yours to manage.

3. "Is the response schema documented? Is there an OpenAPI spec or equivalent?" — Expect a link. If it does not exist, the integration contract is informal.

4. "How does the system sign webhooks and how do I verify them?" — Expect a concrete mechanism. No signing means no integrity guarantee.

Practical rule: if a provider cannot answer three of these four questions with verifiable evidence, you are not evaluating a professional service. You are evaluating a glorified downloader with a polished front-end. Keep looking.

4. Common mistakes when evaluating

Four mistakes. All frequent. The first three happen before a single technical test is run.

❌ Stopping at price. Integration cost, the cost of maintaining your own diff logic, and the cost of a compliance error that slipped through because the dataset was 48 hours stale do not appear on the monthly invoice. The upfront price rarely reflects total cost of ownership.

❌ Picking the first result in Google. Search visibility does not correlate with technical quality or regulatory update rigour. High SEO presence and disciplined update cadence are independent variables, and they often do not go together.

❌ Not testing the integration before signing. Good documentation can mask very different real behaviour. Ask for a trial access, connect your pipeline, verify that diffs work as advertised and that webhook signatures validate correctly. If they do not offer a trial, there is something they do not want you to discover before you commit.

❌ Not checking the real update cadence over the past year. A provider may have had an impeccable cadence in Q1 and slowed significantly in Q2 for reasons they will not volunteer. Ask for the update history of the last twelve months. If it does not exist or they will not share it, assume the worst case and price it accordingly.

5. The final test: does it scale with your business?

The scale test is the criterion least evaluated at purchase time and most painful to discover in production.

An integration that runs cleanly on fifty active ingredients can behave very differently at five hundred if the service does not deliver incremental diffs. The reason is arithmetic: with full dumps, processing volume grows linearly with dataset size. With incremental diffs, processing depends on the volume of changes — which is typically a small fraction of the total, independent of how large the portfolio is.

The concrete question: "how does the changes endpoint perform if my portfolio has 5,000 active ingredients?" The answer tells you whether the system was designed for scale or for the simplest possible use case.

Add to that latency behaviour: do response times stay consistent under load, or does the provider have rate limits that are not documented until you hit them? In a compliance process running as a background job every night, latency that doubles under load can turn into a silent timeout failure that nobody notices until it is too late.

An integration that works at 50 products can collapse at 500. At 5,000, it may simply not be viable if the design never contemplated that scenario.

6. Bottom line

Evaluating a CosIng data source — whether a CosIng API, a managed service, or any alternative to the official cosmetic regulatory database — is not just a technical decision. It is a compliance decision, an architecture decision, and a scale decision at the same time.

The seven criteria above are not exhaustive, but they cover the most common risk vectors. Use them as a checklist before committing to any provider:

1. Dataset freshness with verifiable evidence
2. Incremental diffs with a documented endpoint
3. Structured format with a published schema
4. Traceability back to the official source
5. Active delivery via webhook
6. Verifiable payload signing
7. Active regulatory support through structural changes

If you already have a source, score it against all seven. If most are green, keep it. If not, the conversation is worth having before the problem arrives as a compliance error in production.