Can an AI agent query and interact with Altinn APIs?

What can an agent do today, and what is not offered?

The read surface is live and answers against real registry data. An agent can resolve a company from a name, pull its context, ask what it must file and when the next deadlines fall, and resolve who holds signing authority. Those are ordinary authenticated calls, they return a normalised schema across Brønnøysund and the Rulebook, and each response carries the rule version and data freshness it was produced under.

Validation is not. The execute endpoint with dry_run=true, which used to run a payload through the rule engine and report each check, was parked together with the MVA line on 2026-10-21 and answers 410 CAPABILITY_WITHDRAWN. Nothing on the write-shaped paths runs today, in production or in the sandbox.

Binding submission was never live, and it is not coming through Apier. Altinn Servicedesk confirmed in writing on 2026-10-21, after legal review, that Altinn Autorisasjon data cannot be the basis of a commercial service, with or without a system user, and the “agent drafts, human submits” MVA line stays parked until Digdir or Skatteetaten answer in writing whether a system vendor may offer it. Until then a filing reaches Altinn the way it always has: through the company's own system user or a person who logs in.

Why is the write side withdrawn rather than gated?

Because the ground under it moved. The filing line was built on two assumptions: that Apier could hold an Altinn system user on a customer's behalf, and that a vendor could offer MVA submission once the Skatteetaten scope arrived. The first was answered on 2026-10-21: Altinn Servicedesk confirmed, after legal review, that Altinn Autorisasjon data cannot be the basis of a commercial service, with or without a system user. Apier withdrew the Altinn based authority tools the same day and does not read Altinn Autorisasjon at all.

The second is open, and Apier treats open as no. The MVA line is parked until Digdir or Skatteetaten answer in writing whether a system vendor may offer it, and a parked route does not answer with a stub success or a mock: it answers 410 CAPABILITY_WITHDRAWN with an explanation, so an agent cannot mistake it for a gate that might open on retry. Withdrawn is the honest word because nothing behind the route runs.

For agent design the useful consequence is that the read side is safe to call speculatively and complete on its own. An agent that establishes the obligation, the deadline and the person who may sign gives a user something concrete to act on. The MVA deadline guide covers the timing half of that preparation in detail.

Where does the human decision sit now?

In the company, with the person whose registered authority covers the step. That was always the legal position; what changed is that Apier no longer offers an approval mechanism around it. The scope prefixes that would release a binding action remain reserved and cannot be assigned to any API key, so no key in circulation can be talked into a submission, but there is also no pending action, no approval link and no human-in-the-loop route to call. Those routes were built for the MVA line and are parked with it.

What Apier answers instead is the question before the approval: who may sign. /api/v1/company/{org}/authority returns the registered signaturrett and prokura from Brønnøysund, with the source and the date it was read, and classifies the result as sole, joint, by role, prokura only or no authority. A joint answer means two signatures are required, and the correct agent behaviour is to hand the decision to those people rather than to retry.

So the shape for a product is unchanged on the agent's side: the agent prepares, with the obligation, the deadline and the signatory established and cited, and a named person decides. The deciding happens in the company's own systems, and the filing, where there is one, goes through the company's own channel into Altinn.

Make the first call

The first request needs no key and submits nothing: it reads who may sign for the sandbox company. The second is the production deadline read, and the field to act on first is due_at.

# 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

// Read before you plan: the deadlines a company carries, with the
// rule version on the envelope. Nothing is submitted anywhere.
// Replace {org} with a real organisasjonsnummer; 999999999 exists only in the sandbox.
const res = await fetch(
  "https://www.apier.no/api/v1/company/{org}/deadlines",
  { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);

if (!res.ok) {
  // Every non-2xx answers the same structured envelope.
  const { error_code, explanation } = await res.json();
  throw new Error(`${error_code}: ${explanation.summary}`);
}

const { data, _meta } = await res.json();
// Each entry names the obligation, the period and the effective,
// already weekend-shifted due date.
for (const entry of data.deadlines) {
  console.log(entry.obligation_id, entry.period_label, entry.due_at);
}
console.log(_meta.rulebook_version);

Frequently asked questions

Can an AI agent submit a form to Altinn today?

Not through Apier. Apier does not submit forms to Altinn, does not validate payloads for submission and holds no system user for your customers. The MVA line was parked on 2026-10-21 and the Altinn based tools were withdrawn the same day; every related endpoint answers 410 CAPABILITY_WITHDRAWN. An agent reaches Altinn only through a system user the company itself approves for a registered vendor system, outside Apier.

What does an agent get from the sandbox then?

Proof that your read path is correct. The sandbox answers the production response shape from synthetic fixtures, deterministically, so you can assert on it in a test suite, and it injects failure cases on request so your error handling is exercised. It never calls a government system on any verb, and it offers no submission path.

What happened to the dry run?

It was withdrawn with the MVA line. The execute endpoint with dry_run=true used to check a real payload against the rule set; since 2026-10-21 it answers 410 CAPABILITY_WITHDRAWN, like every other filing route. Reads were never affected: obligations, deadlines and signing authority answer as before.

Who approves a binding filing, then?

A person in the company whose registered authority covers it, inside the company's own channel. Apier's part is to say who that is: GET /api/v1/company/{org}/authority returns signaturrett and prokura from Brønnøysund with source and date, so the agent can route the decision to the right human instead of guessing.

How do I know which capability is live right now?

Two sources, and they agree by construction. GET /api/v1/capabilities returns a machine-readable status field on every capability, which is the one to read if you are a machine. The capability status page in the docs is the human-readable equivalent and is explicit that it may lag the API.