What is the fastest way to start?

The zero-auth sandbox. It answers the production response shapes from synthetic fixtures with no key, no certificate and no account, so you can have a working client the same afternoon you decide to build one. Get the data shape right there, then swap in a key and drop the sandbox prefix from the path.

How much can I build before I have credentials?

The whole client, plus the parts of your product that consume it. The sandbox is deterministic, so you can write real tests against it rather than tests that tolerate variance, and it injects the four common failure cases on request so your error handling is exercised. What you cannot do is prove anything about a real government round trip.

What actually changes between the sandbox and production?

The path prefix and one header. Response shapes are the same by design, which is the point of mirroring them. What changes underneath is that the data is real, that rate limits apply per key rather than per IP, and that company-private facts require the customer's delegation rather than being present in a fixture.

Do I need a key for everything?

No. Public infrastructure endpoints, the tool listings and the capability manifest are zero-auth by design and stay that way, because they exist for discovery rather than revenue. Anything about a named company needs a key even on the free tier, since that data is personal-adjacent: board members, signing authority, filing behaviour.

When should I build the integration myself instead?

When you need an agency or service that is not brokered, when you are a public body with a service-owner relationship that gives you access a commercial integrator cannot have, or when the integration is your product rather than a dependency of it. In the last case the certificate lifecycle and the schema mapping are the thing you are selling, so owning them is the point.

What is the fastest way to build software that works with Norwegian public services?

Start against the zero-auth sandbox, get the data shape right, then swap in a key. The reason this order wins is not that the sandbox is clever but that the setup work is the long pole: certificates, terms of use and registrations move on other organisations' calendars, while the client code is a few days. Build the days-long part first and run the months-long part in parallel. When credentials arrive you change a path prefix and add one header.

The interesting number under each stage is not what it does but what it costs to enter. Two of the three are things you can do today, and the third is the only one that needs somebody else.

What can I build before any credentials exist?

Effectively the whole client. The public sandbox mirrors production response shapes from synthetic Norwegian company fixtures and needs nothing at all: no key, no certificate, no account, no delegation. You can write the request layer, the parsing, the domain model you map responses onto, and the parts of your product that render the result, before anyone has signed anything.

Two properties make that time well spent rather than throwaway work. The sandbox is deterministic, so the same request returns the same body and you can write ordinary assertions instead of tests that tolerate variance. And it injects failure cases on request: a simulate_error parameter produces the missing-delegation, invalid-token, validation and missing-scope responses, in the same structured shape production uses. Error handling written against those is error handling that works.

The honest limit is that none of it proves anything about a real government round trip, because the sandbox never calls a government system on any verb. It tells you your client is correct. It does not tell you a filing would succeed. Treat it as the tool for getting the shape right, which is what most of the calendar goes on anyway.

What is the shortest path to a real call?

Some calls are already real and need nothing. The obligation template for an entity type, the recurring deadline calendar, the capability manifest and the tool listings are all zero-auth by design and answer against live data. If your product needs to know what a Norwegian limited company must file, you are done: no account, no key, no waiting.

For anything about a named company, the shortest path is a key. Drop the sandbox/public prefix from the path you have already been calling and add an Authorization: Bearer header. That gets you the open registry tier for any organisation: what it is, whether it is active, who may sign for it, its published accounts, and the obligation evaluation those facts produce. No certificate is involved on your side, because the government credential chain sits behind the call rather than in your code.

The last stage is the one nobody can shorten. Company-private facts need that company's delegation, which is a decision only the company can make. What you can control is how easy you make it: ask for a narrow set of rights, explain what each is for, and check the grant before every action rather than assuming it persists. See the System User delegation guide for what the customer actually sees.

When is building it yourself the right answer?

More often than a vendor page usually admits. The clearest case is coverage: if you need an agency, a service or a data set that is not brokered, a broker cannot help you and adding one is a dependency without a corresponding benefit. Check the capability listing against your actual requirements before you decide, rather than against the shape of your requirements as you imagine them.

The second case is who you are. Public agencies have access routes that are closed to commercial integrators, and if you have a service owner relationship you should use it rather than routing around it through a third party. The third case is the honest one: if the integration is your product rather than a dependency of it, the certificate lifecycle, the schema mapping and the delegation flow are the thing you are selling. Outsourcing them means outsourcing what makes your product yours.

Where a broker earns its place is the middle case: you need Norwegian compliance data to make some other product work, the integration is not your differentiator, and the cost you are avoiding is not the first build but the ongoing one. Certificate renewals, key rotation, upstream schema drift and delegation handling do not stop after launch, and that recurring load is the honest comparison rather than the first sprint.

Make the first call

These two are the same request at two stages. Note how little changes between them, which is the property that makes starting in the sandbox worth doing rather than a detour.

# Stage one. No key, no certificate, no delegation, no account.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/summary

// Stage two: the same path without the sandbox prefix, plus a key.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/summary",
  { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);

const { data, _meta } = await res.json();
console.log(data.name, _meta.rulebook_version, _meta.data_freshness);

Frequently asked questions

What is the fastest way to start?: The zero-auth sandbox. It answers the production response shapes from synthetic fixtures with no key, no certificate and no account, so you can have a working client the same afternoon you decide to build one. Get the data shape right there, then swap in a key and drop the sandbox prefix from the path.
How much can I build before I have credentials?: The whole client, plus the parts of your product that consume it. The sandbox is deterministic, so you can write real tests against it rather than tests that tolerate variance, and it injects the four common failure cases on request so your error handling is exercised. What you cannot do is prove anything about a real government round trip.
What actually changes between the sandbox and production?: The path prefix and one header. Response shapes are the same by design, which is the point of mirroring them. What changes underneath is that the data is real, that rate limits apply per key rather than per IP, and that company-private facts require the customer's delegation rather than being present in a fixture.
Do I need a key for everything?: No. Public infrastructure endpoints, the tool listings and the capability manifest are zero-auth by design and stay that way, because they exist for discovery rather than revenue. Anything about a named company needs a key even on the free tier, since that data is personal-adjacent: board members, signing authority, filing behaviour.
When should I build the integration myself instead?: When you need an agency or service that is not brokered, when you are a public body with a service-owner relationship that gives you access a commercial integrator cannot have, or when the integration is your product rather than a dependency of it. In the last case the certificate lifecycle and the schema mapping are the thing you are selling, so owning them is the point.