What is an Altinn System User?

It is a machine identity that belongs to a customer company and points at a vendor's registered system. The company grants it rights in Altinn, and your integration then acts under that grant rather than under any employee's login. The system is registered once by the vendor; the System User is created per customer, by that customer.

Can I just use an employee's Altinn login instead?

You can technically automate a personal login, and it is a bad idea for reasons that show up later rather than immediately. The access follows a person, so it disappears when they change role or leave, it carries whatever rights that person happens to hold rather than the narrow set your integration needs, and the audit trail records a human doing something a machine did. System Users exist to remove all three problems.

Do I need my own Maskinporten client for System User delegation?

Only if you integrate directly. Direct means your own Maskinporten client anchored on an enterprise certificate, signed Digdir terms of use, and your own entry in the Altinn System Register. Through a broker those legs belong to the broker. The per-customer delegation is the one leg that cannot be brokered away, because only the customer can grant rights over its own affairs.

How do I know whether a customer's delegation is still valid?

Check before you act rather than after you fail. GET /api/v1/auth/permissions/{org} answers HTTP 200 with a verdict in data.status of full, partial or none, plus the scopes that are active, the ones that are missing, and Norwegian fix steps you can show the customer. Treat a non-full verdict as a normal branch in your code, not an error path.

What happens if a company revokes access?

The next authority check returns a narrower verdict, and any action that depended on the withdrawn rights stops being permitted. Revocation is recorded as a new state rather than by erasing the old grant, so the history of what was permitted when survives the withdrawal. That matters when you have to explain an action taken months ago.

How does Altinn System User delegation work?

A company grants a named, registered software system the right to act on its behalf in Altinn, scoped to specific access packages, without anyone handing over a personal login. The vendor registers the system once. Each customer then makes its own grant, and that grant is what your integration acts under. Because the authority belongs to the company rather than to an employee, it survives staff changes and can be narrowed or withdrawn by the company at any time.

The top row is work a vendor does once. The dashed arrow is the part that repeats for every customer, and it is the only leg a vendor cannot perform on its own behalf.

What is the difference between a System User and a personal Altinn login?

A personal login authenticates a human being. Everything that follows is scoped to whatever that person is entitled to do, which is usually much more than your integration needs and is tied to their continued employment. A System User authenticates a system, for one company, with a set of rights that company chose deliberately. The difference sounds administrative until the first time an accountant changes jobs and half your customers' automations stop working on the same morning.

There is a second difference that matters more for anything autonomous. When a machine acts under a person's credentials, the record says the person did it. That is not a technicality if the action was a filing, and it is close to indefensible if the caller was an AI agent. A System User keeps the record honest: the system acted, under a grant the company can produce, within rights the company chose.

The model is also the only one open to commercial integrators. Altinn confirmed in May 2026 that serviceowner instance scopes are reserved for public agencies, so there is no wider door to walk through. Every private integration works through customer-delegated System Users, which means the delegation flow is not an optional convenience layer you can defer.

How does a company grant access to my system?

Someone at the company who holds the authority to do so signs in to Altinn, finds your system by name, and grants it the access packages it needs. An access package is a bundle of rights described in business terms rather than as raw endpoint scopes, which is what makes the screen answerable by a finance manager instead of only by a developer. Your job in that flow is mostly to have made your system findable and to have asked for a set of packages narrow enough that the person approving it does not hesitate.

Before that screen exists there is vendor-side setup: a Maskinporten client, signed terms of use with Digdir, and an entry in the Altinn System Register so your system has a name to be found under. Through a broker those three belong to the broker. The System Users setup guide in the docs walks the full three-leg configuration if you are building it yourself.

Once a grant exists, do not assume it. Ask. Calling GET /api/v1/auth/permissions/{org} before an action returns a verdict of full, partial or none, together with the scopes that are live, the ones that are missing, and Norwegian fix steps written to be shown to the customer. The endpoint answers HTTP 200 in all three cases, because “not authorised yet” is a state of the world, not a failure of the request.

How do I handle a delegation that has been revoked?

Expect it, and make it boring. A company can narrow or withdraw a grant whenever it likes, and it will not tell your system first. The practical consequence is that the authority check belongs before every action that depends on it, not once at onboarding. A cached “this customer is connected” flag in your own database is a claim about the past.

Design the withdrawal path as a product state rather than an error. When the verdict drops from full to partial or none, the useful behaviour is to pause the affected automation, surface the fix steps to the customer, and keep everything that did not depend on the withdrawn rights running. An integration that responds to a revocation with a generic failure teaches customers that your product is fragile, when what actually happened is that someone exercised a control they were meant to have.

One detail is worth knowing because it shapes what you can answer later. A revocation is recorded as a new state on top of the history, not by deleting the grant that existed. So the question “was this system permitted to do that, on the day it did it?” stays answerable after the access is gone. If you are building anything that a customer or an auditor might ask about retrospectively, keep your own records in the same shape.

Make the first call

The two calls answer two different questions that are easy to conflate. The first asks the registry who may sign for a company at all. The second asks whether that company has granted anything to you.

# Zero-auth sandbox: who may sign for a company, from the registry.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/authority

// Delegated authority. Always HTTP 200; the verdict is in the body.
const res = await fetch(
  "https://www.apier.no/api/v1/auth/permissions/999999999",
  { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);

const { data } = await res.json();

// "full" | "partial" | "none"
if (data.status !== "full") {
  // fix_steps is Norwegian text you can show the customer directly.
  console.log(data.missing_scopes, data.fix_steps);
}

Frequently asked questions

What is an Altinn System User?: It is a machine identity that belongs to a customer company and points at a vendor's registered system. The company grants it rights in Altinn, and your integration then acts under that grant rather than under any employee's login. The system is registered once by the vendor; the System User is created per customer, by that customer.
Can I just use an employee's Altinn login instead?: You can technically automate a personal login, and it is a bad idea for reasons that show up later rather than immediately. The access follows a person, so it disappears when they change role or leave, it carries whatever rights that person happens to hold rather than the narrow set your integration needs, and the audit trail records a human doing something a machine did. System Users exist to remove all three problems.
Do I need my own Maskinporten client for System User delegation?: Only if you integrate directly. Direct means your own Maskinporten client anchored on an enterprise certificate, signed Digdir terms of use, and your own entry in the Altinn System Register. Through a broker those legs belong to the broker. The per-customer delegation is the one leg that cannot be brokered away, because only the customer can grant rights over its own affairs.
How do I know whether a customer's delegation is still valid?: Check before you act rather than after you fail. GET /api/v1/auth/permissions/{org} answers HTTP 200 with a verdict in data.status of full, partial or none, plus the scopes that are active, the ones that are missing, and Norwegian fix steps you can show the customer. Treat a non-full verdict as a normal branch in your code, not an error path.
What happens if a company revokes access?: The next authority check returns a narrower verdict, and any action that depended on the withdrawn rights stops being permitted. Revocation is recorded as a new state rather than by erasing the old grant, so the history of what was permitted when survives the withdrawal. That matters when you have to explain an action taken months ago.