Changes

Every change with its before value, its after value, and the date it took effect — not the date we noticed.

Examples

GET /v1/changes
GET /v1/changes?from=2026-01-01
GET /v1/changes?from=2026-01-01&to=2026-01-31
GET /v1/changes?type=tariff
GET /v1/changes?code=101076

Shape

One change

{
  "entity": "tariff",
  "code": "101076",
  "entity_key": "0@2026-01-01",
  "change_type": "updated",
  "effective_date": "2026-01-01",
  "before": { "fee_code": 0, "amount": "32.840000", "valid_from": "2025-01-01" },
  "after":  { "fee_code": 0, "amount": "33.740000", "valid_from": "2026-01-01" },
  "detected_at": "2026-09-21T13:53:27Z"
}

Parameters

Parameter	Values
`from / to`	YYYY-MM-DD, filtering on effective_date
`type`	code, description, tariff, classification
`code`	A single nomenclature code
`limit / cursor`	Standard pagination, max 200

effective_date vs detected_at

effective_date is when the change took effect in the world. detected_at is when we recorded it. Filter on the first: the second depends on our polling schedule, which is not a fact about Belgian healthcare.

Summaries

A month can contain hundreds of thousands of changes, so counts have their own endpoint rather than being something you page for.

Counts

GET /v1/changes/summary?from=2026-09-01&to=2026-09-30
GET /v1/changes/months

Where changes come from

Mostly from the source's own validity windows: a tariff row that ends on 2025-12-31 followed by one that begins on 2026-01-01 is a change effective 2026-01-01. That is not inference, it is what the dates mean — and it is why the feed is years deep rather than starting from when we began collecting.

A description change can have identical before and after text and differ only in authority_id. That is real: the legal instrument behind the wording changed even though the words did not.