How do I integrate with Altinn 3?
Altinn 3 is a REST API, but you cannot call it with an API key alone. Every request needs a Maskinporten access token proving which organisation you are, and anything done on a customer's behalf additionally needs an Altinn System User delegation from that customer proving you are allowed to act for them. Apier brokers both legs behind a single Authorization: Bearer header, so your integration becomes an ordinary HTTPS call against a normalised schema instead of a certificate-and-token pipeline you build and maintain yourself.
What is the easiest way to call Altinn 3 APIs?
Altinn 2 was decommissioned on 19 June 2026, so “Altinn 3” and “Altinn” now mean the same thing. There is no legacy route left to fall back to, and there is no shortcut around the authorisation model either: Altinn confirmed in May 2026 that serviceowner instance scopes are reserved for public agencies, so a commercial integrator works through the customer-delegated System User model or not at all.
That leaves two honest options. Build the credential chain yourself — a Maskinporten client, an enterprise certificate, signed terms of use, a System Register entry, and a delegation flow you walk every customer through — or call a broker that already holds those and exposes the result as an ordinary API. Apier is the second option: one Bearer key, one normalised schema, and the Maskinporten token exchange and delegation lookup happening on the other side of the call.
What that buys you today is the read and verify surface — company context, obligations, deadlines, signing authority, filing history — plus dry-run validation of an action payload before anything is submitted. Binding submission is sandbox-gated: you can build the full call shape against synthetic fixtures, but a real filing does not leave the system yet. That boundary is deliberate and is stated on every response, so an agent can tell a simulated result from a real one without guessing.
Do I still need Maskinporten and a virksomhetssertifikat?
It depends on who holds the credential, and the split is cleaner than it first looks. Maskinporten is Norway's machine-to-machine OAuth2 service: a client authenticates with a signed JWT assertion, and the key behind that assertion is anchored on an enterprise certificate (virksomhetssertifikat) issued to an entity registered in Brønnøysund. A direct integration means you obtain that certificate, upload the key, sign Digdir's terms of use, register your system in the Altinn System Register, and then rotate all of it on a schedule for as long as the integration lives.
Through a broker, none of that is yours. Apier holds the certificate, signs the assertions and rotates the keys; your application sends one Bearer key and never sees a government token. What a broker cannot take off your plate is the delegation: your customer granting your system the right to act for them is a decision only that customer can make, and no amount of infrastructure removes it. The practical difference is that you integrate against one delegation flow instead of also owning a certificate lifecycle. If you want the full mechanics of the OAuth2 exchange, the Maskinporten guide for developers covers the token flow and the pitfalls end to end.
How do I test an Altinn 3 integration without production access?
Use the zero-auth sandbox. Every company endpoint has a mirror under /api/v1/sandbox/public/ that answers the production response shape from synthetic Norwegian company fixtures, needs no API key, and is deterministic across calls — the same request returns the same body, so you can assert on it in a test suite. Failure paths are testable too: a ?simulate_error= parameter injects the missing-delegation, invalid-token, validation and missing-scope cases so your error handling is exercised before it meets a real one.
One property matters more than convenience here: the sandbox never calls a government system. A sandbox filing is a local state transition, not a submission held back — nothing reaches Altinn, Maskinporten or Skatteetaten from that surface. So the sandbox proves your client is correct and proves nothing about a real filing, which is exactly the guarantee that makes it safe to point an autonomous agent at. Start at the sandbox for a copy-paste request, or at the quickstart for the first-call walkthrough.
| Integration leg | Direct against Altinn 3 | Through Apier |
|---|---|---|
| Authentication | Your own Maskinporten client, signed JWT assertions, and an enterprise certificate you obtain and renew. | One Bearer key. The token exchange happens on Apier's side; your code never handles a government token. |
| Per-customer authority | A System Register entry plus a delegation from each customer, tracked and re-checked by you. | Still granted by the customer, but resolved and checked for you — signing authority is a normalised field on the response. |
| Response shape | Each upstream register answers in its own schema; you normalise across Brønnøysund, Altinn and Skatteetaten. | One normalised schema across upstreams, with a _meta envelope carrying rule version and data freshness. |
| Failure handling | Upstream errors arrive in the upstream's own format; you map each one to something your caller can act on. | Structured error_code plus an explanation with fix steps, identical in shape across every endpoint. |
| Test environment | Access to test environments follows the same onboarding gates as production. | Zero-auth sandbox from the first minute, with deterministic fixtures and explicit failure injection. |
Make the first call
The sandbox request below needs nothing at all — no key, no certificate, no delegation. The TypeScript snippet is the production equivalent: same path shape, one header added.
# Zero-auth sandbox: no key, no certificate, no delegation.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/context// Production read. One header — no token exchange in your code.
const res = await fetch(
"https://www.apier.no/api/v1/company/999999999/context",
{ headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);
if (!res.ok) {
const { error_code, explanation } = await res.json();
throw new Error(`${error_code}: ${explanation.summary}`);
}
const { data, _meta } = await res.json();
console.log(data.name, data.status, _meta.rulebook_version);Frequently asked questions
- Is Altinn 3 just a REST API I can call with an API key?
- No. Altinn 3 is a REST API, but it does not issue API keys. Each request carries a Maskinporten access token that identifies your organisation, and anything you do on a customer's behalf additionally requires that customer to have delegated access to your registered system. The HTTP call is the easy part; the credential chain behind it is the work.
- Do I need my own Maskinporten client to integrate with Altinn 3?
- Only if you integrate directly. A direct integration means your own Maskinporten client, an enterprise certificate (virksomhetssertifikat) issued to a Brønnøysund-registered entity, signed Digdir terms of use, an Altinn System Register entry for your system, and a delegation from every customer. Through a broker like Apier, the first four belong to the broker; the per-customer delegation still belongs to your customer.
- Can I use Altinn's serviceowner APIs instead of System Users?
- 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 works through the customer-delegated System User model, where each customer explicitly grants rights to your registered system.
- Can I test an Altinn 3 integration before I have production access?
- Yes. Apier's public sandbox is zero-auth and answers the same response shapes as production from synthetic fixtures, so you can build and test the client before any certificate or delegation exists. The sandbox never calls a government system, which is also why a sandbox filing proves your code path works but proves nothing about a real submission.
- Can Apier submit a filing to Altinn 3 on my behalf today?
- Reads and validation are live: company context, obligations, deadlines, signing authority and filing history answer against real registry data, and payloads can be dry-run validated. Binding submission is sandbox-gated today — the execute path runs against synthetic fixtures, not a real Altinn submission — so treat it as a contract you can build against, not a filing capability you can ship on.