Going live

What you build against the sandbox is meant to graduate to the live base path with as few changes as possible. This guide is the checklist for that switch for the company reads, including the response shapes that do change: what is on today, what you prepare on your side, and what Apier does not offer at all.

Filing submission is not offeredCopy Anchor Link

Apier reads Norwegian company data and signing authority; it does not submit filings, draft filings for submission or rehearse a submission on a company's behalf. The capability surface tells you so in one call:

curl -s "https://www.apier.no/api/v1/capabilities"

Read data.actions:

{
  "dry_run_supported": false,
  "execute_supported": false,
  "action_types": ["mva_melding", "a_melding"]
}

Since 2026-10-21 POST /api/v1/actions/execute, the human-approval routes under /api/v1/actions/pending/{id} and the sandbox rehearsal route answer HTTP 410 CAPABILITY_WITHDRAWN before authentication and make no upstream call. The MVA "agent drafts, human submits" line is parked and is reassessed only with a written answer from Digdir or Skatteetaten; every surface that read Altinn Autorisasjon data (fullmakt, acting capacity, delegation status, Altinn filing history) is withdrawn for good. See the changelog and the capability status page.

What changes at go-liveCopy Anchor Link

The base path, the credential and the data source change, and so do some read-response shapes (see the next section).

Where the sandbox differs from productionCopy Anchor Link

The sandbox company reads carry the production field names beside their own, so code written against the sandbox can read the production names. _meta still differs:

Two further gaps to plan for:

• Deadline dates are fixed. Sandbox deadlines are far-future fixture dates, except the recentlyRegistered magic org (listed in GET /api/v1/sandbox/fixtures), whose next two MVA deadlines are computed from the sandbox clock (?as_of=, else ?mock_date=, else the request date); from_date and horizon_months are accepted but do not filter. For a real calendar window use GET /api/v1/public/deadlines.
• No trusted certificate. The sandbox signs a sandbox certificate with its own private key, which is public on purpose, and publishes the matching public key as untrusted. Use it for rehearsing the verification code only; see How to verify an apier certificate.

Not every production endpoint has a sandbox route at all: company search, profile, snapshot and the change archive are production-only, so test those with a real key.

What stays identicalCopy Anchor Link

The parts of the response contract the sandbox does mirror:

• The error envelope (error_code + Norwegian explanation with English siblings), including every simulate_error shape you rehearsed.
• org_number on the request, and Idempotency-Key semantics on the write endpoints that honour it (webhook subscriptions, the metered company-profile POST).
• The verification certificate shape (?certificate=true on verify and authority), apart from the trust of the signing key noted above.

So your error handling, idempotency and certificate-parsing logic carry over unchanged; your read parsing does not (see the table above). Assert _meta.is_sandbox is absent in production and flip the base path and key in one place.

Magic test organisation numbersCopy Anchor Link

The sandbox reserves a fixed pool of synthetic org numbers in the test-reserved 999* range. Each one deterministically drives a specific error response, so you can rehearse a code path by org number alone, with no query param required. None of them resolves to a real Brønnøysund entity, and none of them passes the MOD-11 check.

These complement the ?simulate_error= query param for deterministic integration testing. The magic-state orgs (bankrupt, struck off, joint signing, prokura only and so on) are listed in GET /api/v1/sandbox/fixtures.

Your pre-flight checklistCopy Anchor Link

Before you point a single read at the live base path, confirm you have:

• Rehearsed the full flow in the sandbox, including the failure modes. Drive every ?simulate_error= token and the magic-value rejections from the fixtures reference so your error handling is exercised, not assumed.
• Priced the work. Company reads are metered; read GET /api/v1/pricing first and check the balance with GET /api/v1/account/credits/balance before a batch. See Agent payments.
• Secret storage for your real key: never in source control, never in a log. Apier stores only its SHA-256 hash.
• A base-path switch behind one config value, so sandbox → live is a single flip, not a code edit.
• An _meta.is_sandbox assertion in your tests, so a misconfigured base path that silently stays on the sandbox fails loudly instead of pretending to read live data.
• An audit read-back after a batch; see Inspecting actions with the audit trail.
• The receipt handle. Keep each response's _meta.response_hash and the X-Correlation-ID header; they are what you hand an auditor.

If you are integrating from outside Norway, the gates that belong to you, to your customer and to the platform are sequenced in What a foreign SaaS must do before serving Norwegian customers.

Read next: Quick start · Fixtures reference · Inspecting actions with the audit trail.