Going live

Everything you build against the sandbox is meant to graduate to real filings unchanged. This guide is the checklist for that switch: what is on today, what flips when live execution opens, what you prepare on your side, and the gates that are outside your control.

Live execution is currently off

Apier exposes dry-run validation today, but does not submit real filings yet. The capability surface tells you so in one call:

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

Read data.actions:

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

While execute_supported is false, a live POST /api/v1/actions/execute does not file anything. Build and verify your whole flow against the sandbox — it mirrors the production request and response shapes exactly — and poll this flag to know when real execution opens. When it flips to true, your already-tested code path works without changes.

mva_melding is the only filing planned to go live first. a_melding live submission stays blocked pending the NAV integration, even after execute_supported flips — check action_types together with the flag.

What changes at go-live

Only the envelope around your request changes — the request and response shapes stay identical to what you tested in the sandbox.

What stays identical

The response contract is what the sandbox faithfully mirrors:

• The signed-receipt shape (data.receipt with altinn_receipt_id, audit_log_id, signature, signature_algorithm).
• The error envelope (error_code + Norwegian explanation), including every simulate_error shape you rehearsed.
• org_number and payload on the request, plus Idempotency-Key semantics. The approval-token gate applies on both surfaces — only its transport differs (sandbox body vs production header; see the table).
• The overall flow: discover the obligation → dry-run → mint an approval token → execute → read the receipt.

So your receipt parsing, error handling, and idempotency logic carry over unchanged. The live request differs in the fields and transport noted above — build it against the MVA filing guide's canonical shape, assert _meta.is_sandbox is absent in production, and flip the base path + key when execute_supported turns on.

Magic test organisation numbers

The sandbox reserves a fixed pool of synthetic org numbers in the test-reserved 999* range. Each one deterministically drives a specific acting-capacity scenario or error response, so you can rehearse a code path by org number alone — no query param required. All are MOD-11-invalid and never resolve to a real Brønnøysund entity.

These complement the ?simulate_error= query param for deterministic integration testing.

Your pre-flight checklist

Before you point a single filing 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.
• Run ?dry_run=true against the live key once execute_supported is true, and confirmed the five prerequisite checks pass for the real org before sending a live execute.
• An Idempotency-Key on every execute. It is required on /api/v1/actions/execute; reuse the same key across retries of one logical filing. See Idempotency and safe retries.
• The approval-token step wired in for the human-in-the-loop gate on binding writes — see MVA filing.
• 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 file.
• An audit read-back after each filing — see Inspecting actions with the audit trail.

The external gates

These are outside your code and outside Apier's request path — they are infrastructure and approvals that must be in place before a live filing can succeed:

• Maskinporten production approval. Apier's production Maskinporten client must be registered and approved by Digdir. Operator detail: Maskinporten production setup.
• Skatteetaten MVA service-owner access. The MVA filing path needs the Skatteetaten service-owner scope approved for Apier.
• A per-company Altinn System User delegation that is reading active. Each company you file for must have delegated the relevant scope to Apier's system user, and that delegation must resolve as active — see How Altinn 3 System Users work.
• Apier's live-submitter flag. The server-side switch that turns execute_supported to true. Until Apier flips it, no live filing leaves the system regardless of your key or the company's delegation.

The first three are company- and integration-specific and can be in place before Apier opens execution; the last is the global on switch. Watch execute_supported on /api/v1/capabilities — it is the single signal that ties them together.

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