Why are Norwegian government APIs so complex to integrate?
The difficulty is not the HTTP. It is the enterprise certificate you have to obtain, the Maskinporten client you have to register and sign assertions with, the terms of use you have to agree with Digdir, the System Register entry that makes your software findable, and the delegation each customer has to grant you. Each agency solved its own version of these problems, at its own time, so the pieces do not compose the way a single vendor's API would. The request you finally send is ordinary. Everything in front of it is not.
What does the setup actually involve end to end?
Start with the certificate. Maskinporten authenticates a client by a signed JWT assertion, and the key behind that assertion is anchored on an enterprise certificate issued to an entity registered in Brønnøysund. Obtaining one is a purchase from a certificate issuer with an identity check attached, and it expires, so the renewal lands in someone's calendar for as long as the integration lives.
Then the client and the paperwork. You register a Maskinporten client, upload the public half of a keypair, and agree terms of use with Digdir for the scopes you intend to use. Then, for anything acting on a customer's behalf, you add an entry in the Altinn System Register so your software exists as a named thing a customer can find and grant rights to. None of these steps is individually hard. The problem is that they are sequential and each one has its own approval loop.
Only then do you get to the delegation, which is the step that never ends: every customer grants your system its own access, and every customer can narrow or withdraw it later. And only after all of that does the code you were actually hired to write begin. If you have ever wondered why a two-week integration estimate turned into a quarter, this sequence is usually the answer.
| Step | What it costs you | Can it be brokered? |
|---|---|---|
| Enterprise certificate | A purchase with an identity check, plus a renewal cycle that recurs for the life of the integration. | Yes. The certificate and its renewal belong to the broker. |
| Maskinporten client | Registration, keypair generation and upload, and key rotation on a schedule thereafter. | Yes. Your code never handles a government token. |
| Terms of use with Digdir | An approval loop outside your control, per scope you intend to use. | Yes, for the scopes the broker already holds. |
| Altinn System Register entry | Registering your software so customers can find it by name and grant it rights. | Yes. Customers grant rights to the broker's registered system. |
| Per-customer delegation | A flow you walk every customer through, and re-check before every action. | No. Only the customer can grant authority over its own affairs. |
| Schema normalisation | Each register answers in its own shape; you reconcile them and maintain the mapping. | Yes. One normalised schema across upstreams. |
Where do most integrations stall?
At the two steps that wait on somebody else. Certificate issuance and terms-of-use approval are not engineering tasks, so they do not respond to the usual levers: you cannot parallelise them, you cannot estimate them from your own team's velocity, and you cannot finish them in a sprint by deciding to. Teams that plan for this start the procurement track on day one and build against something else meanwhile. Teams that do not, discover in week six that the blocker was never the code.
The second stall is architectural and shows up later. It is the moment a team realises the delegation is not a one-time onboarding step but a permanent state that customers change without warning. An integration built on the assumption that a connected customer stays connected will pass every test and then fail in production the first time somebody in a finance department tidies up their access list. Designing the withdrawal path early is cheaper than retrofitting it.
A third one catches people who ported from the old platform. Altinn 2 was decommissioned on 19 June 2026, so any guide, sample or internal wiki page describing Altinn 2 endpoints is describing something that no longer answers. And there is no wider door: Altinn confirmed in May 2026 that serviceowner instance scopes are reserved for public agencies, so the customer-delegated model is the only one available to a commercial integrator.
How do I test without production access?
Use a zero-auth sandbox and get the data shape right while the paperwork moves. Apier's public sandbox mirrors the production response shapes from synthetic Norwegian company fixtures, needs no key and no certificate, and is deterministic: the same request returns the same body, so you can assert on it in a test suite rather than writing tests that tolerate variance.
Failure paths are testable too, which matters more than the happy path here. A simulate_error parameter injects the missing-delegation, invalid-token, validation and missing-scope cases, so your error handling meets each of them before a real customer does. And the sandbox never calls a government system on any verb, which is the property that makes it safe to point a test suite, or an autonomous agent, at without thinking twice.
What the sandbox cannot tell you is anything about a real submission. That is a limit worth stating plainly rather than discovering: it proves your client is correct and proves nothing about the government round trip. Start at the sandbox for a copy-paste request, and see the fastest-path guide for how far you can get before any credential exists.
Make the first call
The first request exercises a failure path on purpose, because that is the code you will actually spend time on. The second is the production read with the credential chain on the other side of it.
# The zero-auth sandbox: none of the setup chain applies here.
curl -s "https://www.apier.no/api/v1/sandbox/public/company/999999999/context?simulate_error=missing_delegation"// Production read. The credential chain lives on the other side.
const res = await fetch(
"https://www.apier.no/api/v1/company/999999999/context",
{ headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);
if (!res.ok) {
// Structured error, identical in shape across every endpoint.
const { error_code, explanation } = await res.json();
throw new Error(`${error_code}: ${explanation.summary}`);
}Frequently asked questions
- Why can't I just call Altinn with an API key?
- Because Altinn does not issue API keys. Each request carries a Maskinporten access token proving which organisation you are, and that token is obtained with a JWT signed by a key anchored on an enterprise certificate issued to a registered Norwegian entity. Anything done on a customer's behalf additionally needs that customer's delegation. The HTTP call is easy; the credential chain behind it is the work.
- What is a virksomhetssertifikat and do I need one?
- It is an enterprise certificate issued to a registered entity, and it is what anchors the key you sign Maskinporten assertions with. You need one if you integrate directly. Through a broker it belongs to the broker, which also means the renewal cycle and the key rotation belong to them rather than appearing in your backlog every couple of years.
- Can I use Altinn's serviceowner APIs instead?
- No, and neither can any other private integrator. Altinn confirmed in May 2026 that serviceowner instance scopes are reserved for public agencies. Every commercial integration goes through the customer-delegated System User model, so the delegation flow is not an optional layer you can defer to a later release.
- Is Altinn 2 still an option?
- No. Altinn 2 was decommissioned on 19 June 2026, so Altinn and Altinn 3 now mean the same thing and there is no legacy route to fall back to. If you are reading an integration guide that describes Altinn 2 endpoints, it is describing something that no longer answers.
- How long does the setup take?
- Nobody can tell you honestly, because the calendar is set by steps that depend on other organisations rather than on your engineering capacity. Certificate issuance and terms-of-use approval are not tasks you can finish faster by assigning more people. That asymmetry is the reason to start against a sandbox and treat the procurement track as a parallel workstream.