How do I automate Norwegian regulatory compliance tasks?
You compute them instead of looking them up. A Norwegian company's recurring obligations follow from three things that are all machine-readable: its entity type and industry codes in the Brønnøysund registry, its registration and VAT status, and the calendar. Feed those into a versioned rule set and you get the obligation list and the dates it produces, with the rule version stamped on the answer. Apier exposes that evaluation as /api/v1/company/{org}/obligations and /deadlines, so the part you automate is the reaction to the answer rather than the derivation of it.
Which filings can be determined from registry data alone?
More than most teams expect. The Enhetsregisteret record for a company carries its entity type, its NACE industry codes, its registration date, its municipality, whether it is registered for VAT, and whether it is in bankruptcy or under dissolution. Those fields are open data. Between them they settle the majority of the recurring reporting calendar: whether a company reports employee and income data at all, whether VAT returns apply, and which annual filings its legal form obliges it to make.
That is why the zero-auth /api/v1/public/obligations endpoint takes an entity_type and nothing else. Ask it about an AS and it returns the obligation template for a Norwegian limited company, with the legal reference attached to each entry as a field rather than as prose you have to parse. Ask the per-company endpoint instead and you get the same evaluation run against one org number, so the template narrows to the obligations that company actually carries.
What registry data cannot settle is anything keyed to a number the company has not published. Filing frequency thresholds are the common case: a rule that changes behaviour above a turnover or headcount figure cannot be evaluated from a record that does not contain the figure. The response is explicit about this rather than guessing, which matters more than the coverage number.
What do I need a delegation to see?
Anything that belongs to the company rather than to the public record. Every obligations response carries a data_tier field with one of two values. tier_1 means the evaluation ran on open registry facts. tier_2 means the caller held an active delegation from that company, so the evaluation could also read the extended fields the company has authorised you to see. The response also carries an upgrade_path, which is the machine-readable version of “here is what you would need in order to get more”.
The important property is that a tier_1 answer is complete, not truncated. It is a full evaluation over a narrower input set, and any rule it could not reach is reported as unreachable rather than silently dropped or defaulted to a plausible-looking value. A compliance calendar built on tier_1 is correct about what it covers. Adding a delegation widens the coverage; it does not correct an earlier answer that was wrong.
Getting to tier_2 means the company granting your registered system access through Altinn. That is a decision only the company can make, and no amount of infrastructure removes it. The System User delegation guide covers what the grant actually is and how to handle one that is later withdrawn.
How do I keep a deadline calendar current?
Do not cache dates as your own source of truth. A deadline is derived, so it moves when any of its inputs move: the company's registry facts change, the rule set is updated, or the statutory date lands on a weekend or a public holiday and shifts. Cache the answer if you like, but cache it with the rulebook_version it was produced under, and treat a version change as a reason to re-evaluate rather than as a cosmetic field.
The /deadlines endpoint takes from_date and horizon_months, so a nightly job that asks for the next twelve months per company is usually enough for a calendar view. For change detection without a full re-sweep, GET /api/v1/changes returns the change archive across registry and policy sources with filters on source, entity and date, and each row carries the field path that moved. Poll that, re-evaluate the companies it names, and leave the rest alone.
One more thing is worth building in early. Store the correlation id from the response header alongside whatever you write to your own records. Every Apier response carries X-Correlation-ID, and the same value is written to the audit trail behind the call, so when someone asks six months later why your product told a customer a deadline was on a particular date, you can reconstruct the exact evaluation instead of reproducing it from memory. That is cheap to add at the start and awkward to retrofit.
| Obligation area | Who it applies to | What triggers it |
|---|---|---|
| Employee and income reporting | Any entity that pays salary or other reportable remuneration, regardless of legal form. | Having reportable payroll at all. Open registry data tells you the entity exists and its form; whether it currently pays salary is company state. |
| VAT reporting | Entities registered in the VAT register. | VAT registration status, which is an open registry field. Reporting frequency can additionally depend on turnover, which is not. |
| Annual accounts | Legal forms with a statutory accounting duty, notably AS. | Entity type alone, which is open registry data. The filing window follows the financial year. |
| Annual tax return | Applies across forms, but the form and deadline differ between an AS and a sole proprietorship. | Entity type, which is open. Which schedules attach can depend on company-private figures. |
| Industry-specific reporting | Entities whose registered activity falls in a regulated sector. | NACE codes, which are open registry data, though the detailed obligation set varies by supervising body. |
Make the first call
The first request needs no key: it returns the obligation template for a Norwegian limited company. The TypeScript snippet is the per-company equivalent, and the field worth reading first in its response is data_tier.
# Zero-auth: the obligation template for a Norwegian AS.
curl -s "https://www.apier.no/api/v1/public/obligations?entity_type=AS"// Per-company evaluation. One header, one normalised answer.
const res = await fetch(
"https://www.apier.no/api/v1/company/999999999/obligations",
{ headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);
const { data, _meta } = await res.json();
// data_tier tells you whether a delegation widened the answer.
console.log(data.entity_type, data.data_tier);
for (const obligation of data.obligations) {
console.log(obligation.obligation_id, obligation.legal_reference);
}
console.log("evaluated against rulebook", _meta.rulebook_version);Frequently asked questions
- Can I work out a Norwegian company's filing obligations without asking the company?
- Most of them, yes. Entity type, industry codes, registration status and VAT registration are open registry facts, and the majority of recurring obligations follow from those plus the calendar. What you cannot derive from public data is anything that depends on figures the company has not published, such as employee counts or turnover thresholds that move a company between filing frequencies.
- What is the difference between tier_1 and tier_2 data?
- Every obligations response carries a data_tier field. tier_1 means the evaluation used open registry facts only. tier_2 means the caller held an active delegation from that company and the evaluation could also read company-private fields. A tier_1 answer is not a partial answer, it is a complete answer over a narrower set of inputs, and the response says which rules it could not reach.
- Does automating compliance mean the software decides what the law says?
- No, and a design that worked that way would be hard to defend. The rules live in the database as versioned data rather than in application code, every response carries the rulebook_version it was evaluated against, and the same inputs against the same version always produce the same output. You get a reproducible answer you can point at, not a judgement.
- How do I know when an obligation changes?
- Two signals. The rulebook_version on every response moves when a rule changes, so a client that stores it can detect that an earlier answer was produced under different rules. Separately, GET /api/v1/changes returns the change archive for registry and policy sources, filterable by source and date, so you can poll for movement rather than re-evaluating every company on a schedule.
- Can I automate the filing itself, not just the deadline tracking?
- Partly, today. Payload validation runs against the real rule set through the dry-run surface, and the sandbox will accept a full submission call shape so you can build and test the whole path. Binding submission to a government system is gated and is not something you can ship on yet. The capability status page states which side of that line each endpoint sits on.