Provenance on Every Answer: How Fuentio Shows the Source, Licence and Check Time of Company Data

A company fact without its source and date is an opinion. "Active" means little until you know who said it and when. That's why every answer from Fuentio carries its provenance: the official source, the licence that allows reuse, when the source last updated the record, and when we last checked it. This page explains each field, how to read it, and how to file it so the check holds up months later.

The fields below are taken from real recorded API answers; the method is as of 10 October 2026.

Short answer: each Fuentio record has a provenance block (source, source_url, license, fetched_at, last_verified_at, source_updated_at, coverage_level) and each answer a meta block (source, fetched_at, last_verified_at, stale, request_id). Store them next to the fact you used: together they show what the official register said, under which terms, and when.

What you'll learn

• What each provenance field means
• The difference between three dates that look alike
• What stale and coverage_level tell you
• How to file a check for an auditor
• What provenance doesn't prove

What does a provenance block look like?

This is the provenance of a real French record (Renault), as the API returns it:

"provenance": {
  "source": "fr_recherche_entreprises",
  "source_url": "https://recherche-entreprises.api.gouv.fr/search?q=441639465&per_page=1",
  "license": "Licence Ouverte / Etalab 2.0 (Annuaire des Entreprises, INSEE Sirene); officers: INPI RNE reuse licence",
  "country": "FR",
  "fetched_at": "2026-10-05T14:02:11Z",
  "last_verified_at": "2026-10-05T14:02:11Z",
  "source_updated_at": "2026-10-05",
  "coverage_level": "full"
}

And of a real Spanish record, read from the BORME:

"provenance": {
  "source": "es_borme",
  "source_url": "https://www.boe.es/diario_borme/txt.php?id=BORME-A-2026-191-01",
  "license": "Basado en datos de la Agencia Estatal Boletín Oficial del Estado (BORME), https://www.boe.es — reuse conditions: https://www.boe.es/informacion/aviso_legal/",
  "country": "ES",
  "fetched_at": "2026-10-05T14:02:11Z",
  "last_verified_at": "2026-10-05T14:02:11Z",
  "source_updated_at": "2026-10-02",
  "coverage_level": "events_only"
}

What does each field mean?

Three dates that look alike

People often mix up these three, and they answer different questions:

• source_updated_at: when the register last changed its data. For Spain, it's the BORME publication date of the latest act. This is what the official licences ask reusers to show.
• fetched_at: when we first read this version.
• last_verified_at: when we last confirmed it. For a decision you take today, this is the date to keep.

A record can be verified today (last_verified_at) while the register hasn't changed it for months (source_updated_at). That's normal, and it's useful information: nothing new has been registered.

What do stale and coverage_level tell you?

stale sits in each answer's meta. We serve a stored record when it's younger than seven days, and fetch it again when it's older. If the official source is down, we serve our last copy with stale: true and its real last_verified_at, rather than failing or pretending it's fresh. If you need a fresh answer for a decision, treat stale: true as "retry later".

coverage_level says how to read an absence. For France (full), the record reflects the public register. For Spain (events_only), we hold what the BORME has published since 6 October 2025; a fact that was never published in that window isn't in the record, and an "unknown" status isn't "active". See how we turn the BORME into records.

How should you file a check?

For each company fact your process relies on, store:

1. The fact, with its original wording (for example status.original_label).
2. source and source_url: where it came from.
3. last_verified_at: when it was checked.
4. source_updated_at: how current the register was.
5. stale: whether it was a live or a fallback answer.
6. request_id: to quote if you ever need to ask us about that answer.
7. Your decision, who took it, and when.

That's a check you can show an auditor, a partner bank or your own risk committee without re-running anything. For the wider onboarding pattern, see automating onboarding with a register check.

A worked example

Say you onboard a French customer on a Monday. Your file says:

• Fact: status active, original label "Active", as of 2025-12-06.
• Source: fr_recherche_entreprises, with the source URL.
• Licence: Licence Ouverte / Etalab 2.0; officers under INPI's RNE licence.
• Checked: last_verified_at on that Monday; source_updated_at the day before.
• Stale: false.
• Decision: approved by your onboarding rule, version and date noted.

Six months later, the company ceases. Your file still shows, without ambiguity, that on the day you approved it, the official source said it was active, and when the source had last updated it. Nobody has to argue about what was known when.

Why licences belong in your file

Official data is free to reuse, but not without conditions. Etalab's open licence, INPI's RNE licence and the BOE's reuse conditions all ask reusers to cite the source, and most ask for the date of last update. The RNE licence and the BOE's conditions add duties on personal data, and the BOE forbids distorting the meaning of the information.

If your product shows register facts to your own customers, those duties travel with the data. Keeping license and source_updated_at next to each fact means you can display the right attribution anywhere you reuse it, and show later that you did. See what personal data we keep.

What provenance doesn't prove

• It shows what the official source said, not that the source is right about the world.
• It doesn't replace checks the register can't answer: who's behind the company, whether it will pay, whether your contact really works there.
• It isn't legal advice on what your obligations are.

Being explicit about these limits is part of the provenance: a check that claims more than it can prove is a liability. See why AI agents get company data wrong for what happens when facts travel without their source.

Fuentio's API isn't open yet. Become an early tester to see provenance on your own companies before launch.

See what we cover in France and Spain.

Limits. Field names and examples come from recorded answers of Fuentio's API; the method is as of 10 October 2026. Licence texts come from the publishers (Etalab, INPI, BOE). Provenance shows what a source said and when; it doesn't certify the underlying facts. Not legal advice.

Frequently asked questions

What is data provenance in a company data API?

The fields that say where each record came from, under which licence, when the source updated it and when it was last checked.

Which date should I keep as proof of a check?

last_verified_at, the time we last confirmed the record against the official source, together with source_updated_at.

What does stale: true mean?

The official source wasn't answering, so you got our last stored copy, with its real check time.

Does provenance prove a company is legitimate?

No. It proves what the official register said and when. Legitimacy needs other checks.

Sources

• API Recherche d'entreprises, documentation: recherche-entreprises.api.gouv.fr
• Licence Ouverte 2.0 (Etalab): etalab.gouv.fr
• INPI, RNE reuse licence: inpi.fr
• BOE, legal notice and reuse conditions: boe.es