How to follow changes to the law sections the Rulebook cites
Apier keeps a daily hash snapshot of Lovdata's open datasets and publishes a notice whenever a law or regulation section that a Rulebook requirement cites changes. Read the feed with no API key, or receive the same notices by webhook.
[Cite this as: Apier.no Docs v0.1.0 — last updated 2026-11-05]
Every Rulebook requirement cites the law or regulation section it comes from. Apier keeps a daily snapshot of Lovdata's open datasets (current laws and current central regulations, published under NLOD 2.0) as SHA-256 hashes, and hashes each section a requirement cites. When the hash of a cited section moves, Apier publishes a regulatory change notice.
A notice tells you that the published text of a cited section changed, on which day Apier saw it, and which requirements cite it. It carries no law text, no summary and no interpretation: read the section itself on lovdata.no. Lovdata is the source of every notice.
Step 1 — Read the feed
curl "https://www.apier.no/api/v1/public/regulatory-changes?after_id=0&limit=50"The feed is free, keyless and cacheable. Each entry in data.notices names:
| Field | What it is |
|---|---|
section_id | Lovdata's section id, for example NL/lov/1997-06-13-44/§7-6 |
section | The section label within the document, for example §7-6 |
lovdata_document_id | The law or regulation the section belongs to |
dataset | The Lovdata dataset, gjeldende-lover or gjeldende-sentrale-forskrifter |
observed_date | The Europe/Oslo day the snapshot saw the hash move |
effective_date | The document's own date of its last change in force, or null |
requirement_ids | The Rulebook requirements that cite this section |
lovdata_url | The section on lovdata.no |
source | name (Lovdata), licence (NLOD 2.0), source_url (the dataset file) and retrieved_at (when it was fetched) |
Notices are sorted by document version, then section id. limit counts
document versions (1 to 100); one version can carry several changed sections.
Step 2 — Page forward
Pass next_after_id from the previous answer as after_id. null means you
have reached the end. Store the last after_id you read and poll from there:
the feed only ever grows, and the same archive state always gives the same
ETag, so If-None-Match answers 304 when nothing is new.
Step 3 — Look up the requirement
A notice links requirements to a changed section, but it never says what the
change means. Read the requirement with
GET /api/v1/public/requirements and the section on lovdata.no, and decide
for yourself whether your use is affected.
Step 4 — Receive notices by webhook
The same notices are published to the change archive as law_section_changed
changes with source lovdata. A webhook subscription receives them only when
its filter names that entity type:
{ "entity_type": "law_section_changed" }Existing subscriptions, including one with an empty filter, do not start receiving these notices. Deliveries are signed and retried like every other change webhook (see Webhooks), and they are free.
What this feed does not do
- It does not store or show the text of any law.
- It does not tell you whether a change affects a company or a requirement.
- It covers only sections a Rulebook requirement cites, from the day Apier first hashed them. A section cited for the first time is tracked from the next day its document changes.
How to check how fresh Apier's sources are
Read the public source health endpoint: last successful fetch, lag, 30-day outage windows, coverage start and licence for every source Apier fetches on a schedule, with no API key.
Unified company snapshot in one call
Fetch verification status, roles, VAT, employer and risk for a Norwegian company in one request: one normalized object, no new government access.