Skip to content
Apier

Apier.no

Government API change policy

Apier sits between your systems and public infrastructure such as Altinn 3, Maskinporten, Brønnøysundregistrene and Skatteetaten. Those APIs change — certificates rotate, schemas grow, endpoints get retired. This page describes how we handle that, and which notice periods you can plan against. We only promise what we can actually keep.

Certificate and key rotation

Authentication against government APIs (Maskinporten keys, TLS certificates) is handled entirely on Apier's side. You never handle government certificates yourself, and a rotation on our side or the agency's requires no change in your integration. Rotations are performed without planned downtime; if a rotation nevertheless causes disruption, it is logged as an incident on the status page.

Upstream schema changes

Every government integration goes through an adapter layer that normalises the agency's response into Apier's own response format. Additive upstream changes (new fields, new codes) are absorbed in the adapter without changing your contract. If an upstream change forces a change in Apier's own response format, it is treated as a breaking change under the rules below.

Exception: if an agency ships an incompatible change on shorter notice than our own notice period, we pass on as much notice as the agency gives us, and say explicitly in the notice that the deadline was set upstream. We do not promise a notice period we do not control.

Endpoint deprecation

When an upstream endpoint is retired (for example in the Altinn 2 → Altinn 3 transition), we migrate the adapter on our side and keep the Apier contract stable where possible. If we remove one of our own endpoints, it is announced at least 90 days before the endpoint stops answering, with a documented migration path in the changelog.

API version support window

  • Additive contract: existing fields in v1 responses never change meaning, type or name, and are never removed. New fields may be added — your client must tolerate unknown fields.
  • Breaking changes: happen only through a new major version (for example /v2), which runs in parallel with the previous one.
  • Support window: the previous major version stays supported for at least 6 months after its successor is generally available.

Notice period and channels

Breaking changes to Apier's own API are announced in writing at least 90 days before they take effect (with the upstream-forced exception described above). Every notice is published in the changelog and its feed — those are the two channels we commit to:

  • Changelog: /docs/changelog — every user-visible API and Rulebook change.
  • Subscribable feed: /changelog.atom (Atom/RSS).
  • Email: where we hold a technical contact for an account, we additionally aim to notify by email. This is a best-effort addition, not a committed channel — the changelog and the feed above are where every notice appears.