A permanent, no-signup test surface that mirrors the production request and response shapes against deterministic synthetic data — and never calls a government system. Use it to rehearse the full authenticated flow, including failures, before you go live. There are two ways in.
How to use the sandbox
1 · Public, zero-auth
The public mirror (/api/v1/sandbox/public/*) needs no key at all and serves org 999999999. Best for a first look at the response shapes.
2 · No-signup synthetic bearer
Pass Authorization: Bearer apier_sandbox_test_<uuid> to reach the eight non-public routes and the richer fixtures. The <uuid> suffix is your private, isolated session namespace — generate a fresh one per agent or run.
Every response is tagged _meta.is_sandbox: true. You can shape behaviour with deterministic knobs — ?simulate_error= for the eight failure modes, ?simulate_latency= to pause a response, and ?mock_date= to pin the clock — and force filing outcomes with magic payload values. Every synthetic org, token, knob, and magic value lives in the fixtures reference.
Paste any of these into live Apier.no calls. The 999xxxxxxx range is reserved for synthetic testing and 123456789 is the docs-standard mock used across the OpenAPI manifest and capability examples. For the full sandbox fixture catalogue — reserved test orgs, the realistic graph, reserved error orgs, and more — see the fixtures reference.
Org number
Name
Entity
Data tier
Scenario
999111114
Synthetic AS with Full Delegation
AS
tier_1+2
AS with full Tier 2 delegation
999222226
Synthetic ENK Sole Proprietor
ENK
tier_1
ENK sole proprietor, no employees
999333338
Synthetic DA Partnership
DA
tier_1
DA partnership (delt ansvar)
123456789
Docs-standard mock org
NUF
tier_1
NUF (foreign branch)
999444008
Sandbox unknown-org placeholder
AS
tier_1
sandbox-unknown-org
Magic state fixtures
Eight reserved org numbers, each one deterministically returning a single documented company state on the authenticated read surface — the regulatory edge cases an agent must learn to handle. Pass the no-signup synthetic bearer and hit /api/v1/sandbox/company/<org>/verify (or /authority, /obligations). This table is generated from the same source as GET /api/v1/sandbox/fixtures.
Org number
State
Entity
/verify
/authority
MVA
Obligations
999660010
Bankrupt (konkurs)
AS
fail
sole
yes
none (company is bankrupt)
999660029
Struck from register (slettet)
AS
fail
sole
no
none (company is deleted)
999660037
Forced liquidation (tvangsavvikling)
AS
fail
sole
yes
none (company is in forced liquidation)
999660045
No registered roles
AS
warn
no_authority
yes
MVA-melding (bimonthly)
999660053
Not VAT-registered
AS
pass
sole
no
none (not MVA-registered)
999660061
Enkeltpersonforetak (ENK)
ENK
pass
sole
no
Skattemelding for næringsdrivende (annual)
999660088
Aksjeselskap (AS)
AS
pass
sole
yes
MVA-melding (bimonthly)
999660096
Registered <30 days ago
AS
pass
sole
yes
MVA-melding (bimonthly)
Try it — public endpoints
Zero-auth, permanently rate-limited per-IP at 1000 req/min (Category A). Every cURL runs against the live production API.
Norwegian business deadlines for a given calendar year
Every deadline is ISO 8601 with the Europe/Oslo offset baked in. `adjusted_from` is non-null when the legal date fell on a weekend or holiday — agents do not need to reimplement Oslo business-day math.
Generic Norwegian business obligations by entity type
`tier_2_required: true` marks obligations that need a Tier 2 delegation before producing a company-specific verdict. Without delegation the `/company/*` endpoints return `insufficient_data` with an `upgrade_path`.
Official Norges Bank NOK exchange rate for a currency and date
`date` is the actual publication day Norges Bank resolved the rate from — on weekends/holidays it falls back to the previous banking day and `requested_date` records what you originally asked for.
{
"success": true,
"data": {
"deprecation_deadline": "2026-06-19T23:59:59+02:00",
"timezone": "Europe/Oslo",
"days_remaining": 57,
"deadline_passed": false,
"entry": {
"altinn2_code": "A0208",
"altinn2_name": "A-melding",
"altinn3_resource": "altinn:serviceowner:skatteetaten:a-melding",
"verified": true,
"migration_notes": "A-melding consumed via the Altinn 3 resource model. Requires a System User delegation with scope altinn:accessmanagement/authorizedparties.read.",
"last_verified_against_digdir": "2026-04-15"
}
},
"_meta": {
"rulebook_version": "1.0.0",
"data_freshness": "2026-04-15T00:00:00.000Z",
"last_verified": "2026-04-15T00:00:00.000Z",
"source": "apier.no",
"schema_version": "1.0.0"
}
}
Omit `altinn2_code` to receive the full `mappings` array. The `deadline_passed` flag flips to `true` at 2026-06-19T23:59:59+02:00 Europe/Oslo — agents should branch on the boolean, not reimplement the date math.
Every authenticated surface is listed with its `auth`, `tier_minimum`, and OpenAPI operation id. Parse this instead of hard-coding endpoint lists in agent prompts.
{
"success": true,
"data": {
"dimensions": [
{
"dimension": "authentication",
"apier": "Consumers authenticate with an API key over HTTPS; Maskinporten client registration, key management, and machine-to-machine token exchange against government endpoints are operated by Apier.",
"direct_integration": "The integrator registers their own Maskinporten client, manages an asymmetric key pair, and implements the signed-JWT token exchange for each government scope they need."
},
{
"dimension": "delegation_and_authority",
"apier": "Registered signature and prokura roles from the Brønnøysund registers and Altinn delegation state are exposed through normalised endpoints with a single response envelope.",
"direct_integration": "The integrator queries the Brønnøysund role registers and the Altinn delegation APIs separately and combines the results themselves."
},
{
"dimension": "audit_trail",
"apier": "API activity is recorded in an append-only audit log, and every response carries provenance metadata (response hash and wire timestamp) for later reconstruction.",
"direct_integration": "Consumer-side audit logging is the integrator's responsibility; the government APIs do not provide one on the caller's behalf."
},
{
"dimension": "legal_grounding",
"apier": "Obligation and deadline answers are produced by a versioned rulebook whose rules carry references to the underlying regulations, and responses state which rulebook version produced them.",
"direct_integration": "The integrator maps regulations to API behaviour themselves and tracks regulatory changes on their own."
},
{
"dimension": "error_handling",
"apier": "Upstream errors are normalised to one structured error format with machine-readable codes, an explanation, and remediation steps.",
"direct_integration": "Each government API surfaces its own error format; the integrator implements per-API error mapping and retry handling."
},
{
"dimension": "deadline_intelligence",
"apier": "Regulatory deadlines are computed in Europe/Oslo time with weekend and Norwegian public-holiday adjustment, versioned by the rulebook.",
"direct_integration": "Deadline rules must be implemented and maintained by the integrator from the published regulations; the government APIs do not compute them."
},
{
"dimension": "cross_agency_orchestration",
"apier": "One API surface spans Brønnøysund, Altinn, Skatteetaten, and NAV data behind a common envelope and a single authentication model.",
"direct_integration": "Each agency is a separate integration with its own authentication, schemas, and lifecycle."
},
{
"dimension": "maintenance_burden",
"apier": "Upstream schema and policy changes are monitored by Apier and surfaced through an append-only change archive; the consumer response contract is append-only.",
"direct_integration": "The integrator monitors each agency's changelogs and migration timelines (for example the Altinn 2 to Altinn 3 transition) and updates their integration accordingly."
},
{
"dimension": "time_to_first_call",
"apier": "Public endpoints and a zero-auth sandbox work without any government onboarding; company-data endpoints require an API key only.",
"direct_integration": "A first production call requires Maskinporten client registration plus the relevant government scope or delegation grants before any data is returned."
}
],
"methodology": "Qualitative comparison based on Apier product documentation and the publicly documented integration requirements for the Norwegian government APIs (Maskinporten, Altinn, Brønnøysund Register Centre, Skatteetaten). Quantitative performance claims (success rates, latency) are intentionally omitted until they can be backed by measured live telemetry.",
"source": [
"Apier product documentation and OpenAPI specification",
"Public Norwegian government integration documentation (Digdir/Maskinporten, Altinn, Brønnøysund Register Centre, Skatteetaten)"
],
"last_updated": "2026-06-12T00:00:00.000Z"
},
"_meta": {
"rulebook_version": "1.0.0",
"data_freshness": "2026-06-12T00:00:00.000Z",
"last_verified": "2026-06-12T00:00:00.000Z",
"source": "apier.no internal comparison",
"served_from": "static",
"schema_version": "2.0.0"
}
}
Designed to be parsed, not rendered — each dimension carries one factual statement per column so agents can weigh Apier against building the direct integration at planning time. The methodology and source fields state the comparison basis on the wire.
Rehearse the full MVA write loop
The five steps a binding VAT filing goes through, run for real against your own account: validate (production dry-run), stage (a real 412 human-in-the-loop suspension), approve (a real single-use token), execute (mock receipt — the submitter is hardcoded to mock, so no government system can ever be reached), and inspect the append-only audit evidence. Every response below is rendered verbatim — including the error responses, which are part of the loop's guarantees.
Before you start
You need a real Apier API key — the no-signup synthetic bearer cannot drive this loop, because every step writes real rows (pending action, token consume, audit trail, signed receipt) keyed to your account. The default key from signup carries the read:* wildcard, which grants all three scopes the loop touches: read:actions (steps 1, 2, 4), read:altinn (step 3) and read:audit (step 5). Nothing here can reach a government system: the rehearsal endpoint hardcodes the mock submitter.
1 · Validate — production dry-run
Runs the real five-check precondition engine (company exists, delegation active, scopes delegated, data format, deadline) without submitting anything. 200 is the success path even when checks fail — verdicts are content. With the synthetic org 999999999 expect company_exists: false; the loop continues regardless: steps 2–5 rehearse the write mechanics, not the precondition verdicts.
Calls the rehearsal endpoint WITHOUT an approval token. The action is staged as a REAL pending_actions row (15-minute TTL) and suspended with 412 HITL_PENDING_APPROVAL. Re-running this step reuses the same Idempotency-Key — the cached 412 replays with the SAME pending_action_id (the Rule 5 replay guarantee, live).
Mints a real single-use approval token bound to (org_number, filing.submit) via the production endpoint. The plaintext is shown ONCE below — only its SHA-256 hash is stored server-side. In production, a human operator performs this step; the approval_url in step 2's response is the production approval surface.
4 · Execute — re-send with X-Approval-Token → mock receipt
Re-sends the same request WITH the token and a NEW Idempotency-Key. The token is consumed exactly-once through the atomic CAS — then the HARDCODED mock submitter produces a receipt (MOCK-ALT-… id, government_response_raw._mock: true), HMAC-signed and persisted. No government system is ever called from this surface. Re-running with the same token shows the real APPROVAL_TOKEN_USED rejection — single-use, demonstrated live.
5 · Evidence — pending-action status + audit chain
Reads the staged pending action via the production status endpoint. On the token path the pending row is not flipped — the consumed token plus the audit rows ARE the authorization record, and the row lapses to EXPIRED after its 15-minute TTL (production semantics, mirrored exactly). The receipt from step 4 embeds audit_log_id and correlation_id — the keys into the append-only audit_log evidence.
The end-to-end sandbox rehearsal, as a check-off list — from fetching the fixtures table to injecting an infrastructure failure and time-traveling a deadline. Check-off state is in-page only and resets on reload.
