Skip to content
Apier.no
Guides

How to read a company's state on a past date and its change history

Call GET /api/v1/company/{org}/as-of for what Brønnøysund's register showed about a Norwegian company at the end of a past day, and GET /api/v1/company/{org}/history for every change Apier observed between two dates or a field-by-field diff.

[Cite this as: Apier.no Docs v0.1.0 — last updated 2026-11-03]

Apier archives what Brønnøysund's register shows for the companies it mirrors every day, starting on 2026-07-30. Two endpoints read that archive:

  • GET /api/v1/company/{org}/as-of?date=YYYY-MM-DD returns the state Apier had observed at the end of that Europe/Oslo day.
  • GET /api/v1/company/{org}/history?from=YYYY-MM-DD&to=YYYY-MM-DD returns every change Apier observed in the window, or, with view=diff, one field-by-field comparison between the end of from and the end of to.

Both are a record of what the register showed when Apier looked. They do not state which facts were in force on a date, and they are never a verdict. Every answer carries that statement in its statement field.

Step 1 — Read the state on a date

curl -H "Authorization: Bearer $APIER_API_KEY" \
  "https://www.apier.no/api/v1/company/999999999/as-of?date=2026-09-15"

999999999 is a placeholder: replace it with the organisation number of the company you want. It is a sandbox fixture and returns no observed state in production.

The key needs the read:brreg scope. date is required and may not be after today in Europe/Oslo.

data.fields lists every tracked field (status, form, NACE codes, VAT registration, roles and the register's coded signing rules for the company, as archived), sorted by name. Each field has a status: verified when Apier had observed it by the end of that day, not_checked when it had not. A field Apier did not observe keeps value: null: it is never filled with today's value or a neighbouring observation.

Step 2 — Read what changed between two dates

curl -H "Authorization: Bearer $APIER_API_KEY" \
  "https://www.apier.no/api/v1/company/999999999/history?from=2026-09-01&to=2026-10-31"

data.changes is ordered by the day Apier observed each change, then by field. Each change carries observed_at (when Apier saw it), effective_at (the official date, where the register gives one; otherwise null), the before and after values, the source and the licence. One answer carries at most 1,000 changes: when the window held more, data.truncated is true and the list is the oldest 1,000, so split the window into shorter ones before you treat the list as complete.

Add view=diff for one comparison per field between the state at the end of from and at the end of to. changed is true or false only when both sides were observed; otherwise it is null and the field is not_checked.

The window is at most 366 days, to may not be after today and from may not be after to. Anything else is refused with 400 VALIDATION_FAILED, never clamped.

Step 3 — Read the coverage window

Every answer carries coverage in its body and in _meta.coverage: archive_start (2026-07-30), entity_first_observed, covered_from (the later of the two) and before_coverage, which is true when you asked about a day before covered_from. A date before the archive start is answered, never refused: the facts are not_checked and the note says nothing before covered_from is known to Apier.

Step 4 — Get a signed copy

Add certificate=true to either call. data is then a verification certificate: data.result is the answer plus latest_anchor, the newest daily anchor Apier has published at /api/v1/public/anchors. Verify the detached signature against /.well-known/jwks.json, as described in the verification certificate guide.

Billing

Each call is billed as one company read. An answer that observed nothing (a date before Apier first observed the company, or an empty window for a company Apier had not yet observed) is not billed. Errors are never billed.

Building with an LLM? Read llms.txt for agent-oriented integration guidance.