Skip to main content
When a number drives a decision, you need to be able to defend where it came from. Financial Data API attaches provenance to every observation and exposes a dedicated endpoint that returns the full chain: the named source, the source URL, a raw payload reference, and the ingestion run that recorded it. Together these let you walk backward from any value in an API response to the official release it originated from.

What every observation already carries

You do not have to make a second call to get basic attribution. Observation responses include, inline:
string
The named publisher the value came from (for example, a central bank or statistics office).
string
A URL pointing at the originating release or dataset.
string
The required attribution string for the value.
string
The freshness label: fresh, stale, or unknown.
boolean
Whether a captured upstream payload is on record for this value. The raw body itself is never returned; this flag proves the value was derived from a specific captured response, retrievable through the provenance endpoint as a reference.
object
Rights and exposure metadata governing how the value may be used.
The raw payload reference is an identifier, not the payload. Financial Data API never re-serves upstream provider bodies; the reference exists only to prove a value was derived from a specific captured response.

The provenance endpoint

For the complete auditable chain on a single observation, call:
string
required
The identifier of the observation you want to trace. You get this from any observation response.
It returns the named source, the source URL, raw payload reference metadata, and the ingestion run that produced the value: an auditable chain from the official release all the way to the API response you received.

Example response

Field names and the exact shape are defined by the OpenAPI spec at GET /openapi.json. Treat the spec as authoritative and read fields defensively.

The auditable chain

Provenance is not a single label. It is a chain of four linked facts, each answering a different audit question.

Named source

Who published this? Identifies the official issuer, for example a central bank or a national statistics office.

Source URL

Where can a human verify it? Points at the originating release or dataset so a reviewer can cross-check by hand.

Raw payload reference

Exactly which upstream response produced this value? A reference to the captured payload, proving the value was not hand-edited, without re-serving the upstream body.

Ingestion run

When and by which run did Financial Data API record it? Ties the value to a specific, timestamped ingestion, which connects provenance to the time model.
Pair provenance with the time model. The ingestion run timestamp is what as_of approximates today, so the provenance chain and a point-in-time query describe the same moment from two angles: one tells you where a value came from, the other when it became known.

A typical audit flow

Find the observation

Query any observation route and read the inline provider, sourceUrl, and rawAvailable. For many audits this is already enough.

Pull the full chain

Call GET /provenance/observations/{observationId} to retrieve the named source, source URL, raw payload reference metadata, and ingestion run together.

Verify against the release

Open the sourceUrl and confirm the published figure matches. The raw payload reference and ingestion run document the path in between.
Every value Financial Data API returns is traceable to an official release. There are no orphan numbers.

Freshness and liveness

How Financial Data API flags stale and silently-frozen feeds.