---
title: "Sandbox explainer with error simulation (zero-auth)"
method: POST
path: "/api/v1/sandbox/explain"
tags: ["Sandbox"]
---

# Sandbox explainer with error simulation (zero-auth)

`POST /api/v1/sandbox/explain`

## Request

- Base URL: `https://www.apier.no`
- URL: `https://www.apier.no/api/v1/sandbox/explain`
- Auth: none required

Sandbox mirror of `POST /api/v1/explain`. Zero-auth; shares the public-sandbox per-IP rate limit bucket (100 requests / hour). Resolves a structured Apier `error_code` into the same Explanation envelope production returns, with sandbox `_meta` (`is_sandbox: true`). `?simulate_error=` forces a deterministic, locally synthesized error response (production-shaped body; no upstream is ever called) so SDK consumers and agent test harnesses can exercise the error contract without real failure conditions. POST body capped at 8192 bytes; an oversized body returns 413 REQUEST_TOO_LARGE naming the 8 KiB cap; empty or non-JSON bodies return 400 VALIDATION_FAILED. Unlike the public twin `/api/v1/sandbox/public/explain`, `context.org_number` accepts any 9-digit value (not gated to 999999999).

## Query parameters

- `simulate_error` 'missing_delegation' | 'invalid_token' | 'validation_error' | 'scope_missing' | 'altinn_timeout' | 'invalid_certificate' | 'malformed_payload' | 'upstream_5xx' | 'AUTH_MISSING_DELEGATION' | 'AUTH_EXPIRED_TOKEN' | 'VALIDATION_FAILED' | 'SCOPE_MISSING'

## Headers

- `X-Correlation-ID` string, uuid

## Request body

- object
  - `error_code` string, required: A structured Apier error code from the Compliance Explainer registry (e.g. AUTH_MISSING_DELEGATION). Codes outside the registry return 400 VALIDATION_FAILED.
  - `context` object: Optional context that specialises the explanation. Each string field is capped at 64 UTF-8 bytes.
    - `org_number` string
    - `scope` string
    - `role` string
    - `field` string
    - `upstream_system` string
  - `context_org_number` string: Flat form of `context.org_number`: the organisation the error relates to (9 digits). Mixing flat context_* fields with the nested `context` object is rejected with 400 VALIDATION_FAILED.
  - `context_scope` string: Flat form of `context.scope`: scope token interpolated into the bokmål explanation. Cannot be combined with the nested `context` object.
  - `context_role` string: Flat form of `context.role`: role code interpolated into the explanation. Cannot be combined with the nested `context` object.
  - `context_field` string: Flat form of `context.field`: field name interpolated into the explanation. Cannot be combined with the nested `context` object.
  - `context_upstream_system` string: Flat form of `context.upstream_system`: upstream system name interpolated into the explanation. Cannot be combined with the nested `context` object.

## Response `200`

Explanation resolved. Same envelope shape as the public twin `/api/v1/sandbox/public/explain`.

- object
  - `success` unknown, required
  - `data` object, required
    - `explanation` object, required
  - `_meta` SandboxMeta, required: Sandbox `_meta` block. NOT a drop-in for production's `TrustMetadata`; clients must branch on `is_sandbox` before assuming any sandbox/production field equivalence. Differences from production: 1. `is_sandbox: true` — load-bearing detection signal; `body._meta.is_sandbox === true` is a single property assertion agents use to verify they're talking to the sandbox. Production omits this key entirely. 2. `rulebook_version` is the literal string `"sandbox"` — production carries the actual Rulebook version (e.g. `"v1.0.0"`). Sandbox responses are not Rulebook-evaluated. 3. `data_freshness` and `last_verified` are pinned constants (2026-01-01T00:00:00+01:00) — production reflects actual cache / fetch state. 4. `response_timestamp` is RFC 3339 with explicit Europe/Oslo offset (`+01:00` CET / `+02:00` CEST, DST-aware) — production's `response_timestamp` carries a UTC `Z` suffix. 5. `response_hash` and `source_snapshot_id` are OMITTED — sandbox writes ZERO provenance_log rows, so a hash without a matching forensic row would be misleading. Only `source` (`"apier.no"`) and `schema_version` semantics are shared with production.
    - `rulebook_version` 'sandbox', required: Always literal `sandbox` — sandbox responses are not Rulebook-evaluated.
    - `data_freshness` '2026-01-01T00:00:00+01:00', date-time, required: Pinned constant (2026-01-01T00:00:00+01:00) for determinism — same value on every call. Schema-locked via `enum` so spec-based drift checks catch any deviation.
    - `last_verified` '2026-01-01T00:00:00+01:00', date-time, required: Pinned constant — equal to data_freshness. Schema-locked via `enum` for the same drift-detection reason.
    - `source` 'apier.no', required: Response origin. Always `apier.no`. Preserves `_meta.source` parity with production `TrustMetadata.source` so clients can reuse `_meta` parsing across both surfaces. Provenance-specific fields (`response_hash`, `source_snapshot_id`) are omitted by design.
    - `schema_version` string, required: OpenAPI document version — mirrors the top-level `info.version` field. Distinct from `/api/v1/capabilities._meta.schema_version` and `/workflows.json.schema_version`, which version the capabilities-discovery and workflows-discovery surfaces respectively. Equality with `info.version` is enforced at CI time.
    - `is_sandbox` true, required: Load-bearing sandbox-detection signal. Always `true`.
    - `response_timestamp` string, date-time, required: RFC 3339 timestamp with explicit Europe/Oslo offset — runtime emits via `formatInTimeZone(now, 'Europe/Oslo', "yyyy-MM-dd'T'HH:mm:ssXXX")` so the offset is DST-aware (`+01:00` in CET / `+02:00` in CEST). The ONLY non-deterministic field permitted on sandbox responses (excluded from determinism comparisons).
    - `sandbox_notice` string, required: Human-readable mock-vs-government honesty signal (item 5). Constant prose: a passing sandbox run is an Apier internal mock (not Altinn TT02 / Skatteetaten test) and does not guarantee real government acceptance. `is_sandbox` is the machine-readable twin; this is the prose an agent or a human reading a logged response sees. Plain ASCII so it never trips the docs bokmål canary.
    - `cost_nok` 0: Always `0`. A sandbox call never debits anything — there is no ledger write and no government upstream. Same field name and rendering as production's `TrustMetadata.cost_nok`, so a client that reads the cost off `_meta` works unchanged against both surfaces. Emitted on every sandbox response. Declared optional in this schema only so the many older sandbox examples in this document stay valid; the runtime builder emits it on every response.
    - `wallet_remaining_nok` unknown
    - `as_of` string: Present ONLY when `?as_of=` Rulebook time travel is active on /deadlines or /obligations. Echoes the agent's exact YYYY-MM-DD input so a transcript is self-describing about which reference date the deadline / obligation statuses were derived against. Absent on every other sandbox response.
    - `simulated` true: Present + `true` ONLY on an `X-Apier-Simulate` injected failure response. The load-bearing signal that a 500 / 504 / 429 is a deliberately-simulated infrastructure failure, not a real one. Absent on every real sandbox response.
    - `session_merged` true: Present + `true` ONLY when this response merged per-suffix session state (mock filings recorded by a prior POST /api/v1/sandbox/actions/execute under the SAME sandbox-bearer suffix) over the static fixture, on the three opted-in reads (/audit, /obligations, /summary). The honesty marker distinguishing fixture state from session state. Absent on every fresh-suffix response, which stays byte-deterministic.
    - `session_merged_rows` integer: Count of response items the merged session state changed (obligation/deadline statuses overridden plus audit rows prepended). Present ONLY alongside `session_merged: true`, always >= 1.

## Other responses

- `400`: Sandbox 4xx / 5xx error from a write-side endpoint (`/api/v1/sandbox/auth/approval-token`, `/api/v1/sandbox/actions/plan`). Body shape mirrors `SandboxError` (the read-side error envelope) but the response carries the write-side CORS contract that `applySandboxWriteSideCorsHeaders` stamps on every error path: `Access-Control-Allow-Methods: POST, OPTIONS`, `Access-Control-Allow-Credentials: false`, and the write-side `Access-Control-Allow-Headers` safe list. Introduced so the published contract for approval-token + plan errors stops drifting from the runtime — they previously reused `SandboxError` which advertises the read-side `GET, OPTIONS` Allow-Methods and omits the explicit `Allow-Credentials: false` write-side guarantee. The execute route uses `SandboxExecuteError` instead because it ships reliability fields (`execution_guarantee` + `outcome`) that approval-token + plan do NOT emit.
- `401`: Sandbox 4xx / 5xx error from a write-side endpoint (`/api/v1/sandbox/auth/approval-token`, `/api/v1/sandbox/actions/plan`). Body shape mirrors `SandboxError` (the read-side error envelope) but the response carries the write-side CORS contract that `applySandboxWriteSideCorsHeaders` stamps on every error path: `Access-Control-Allow-Methods: POST, OPTIONS`, `Access-Control-Allow-Credentials: false`, and the write-side `Access-Control-Allow-Headers` safe list. Introduced so the published contract for approval-token + plan errors stops drifting from the runtime — they previously reused `SandboxError` which advertises the read-side `GET, OPTIONS` Allow-Methods and omits the explicit `Allow-Credentials: false` write-side guarantee. The execute route uses `SandboxExecuteError` instead because it ships reliability fields (`execution_guarantee` + `outcome`) that approval-token + plan do NOT emit.
- `403`: Sandbox 4xx / 5xx error from a write-side endpoint (`/api/v1/sandbox/auth/approval-token`, `/api/v1/sandbox/actions/plan`). Body shape mirrors `SandboxError` (the read-side error envelope) but the response carries the write-side CORS contract that `applySandboxWriteSideCorsHeaders` stamps on every error path: `Access-Control-Allow-Methods: POST, OPTIONS`, `Access-Control-Allow-Credentials: false`, and the write-side `Access-Control-Allow-Headers` safe list. Introduced so the published contract for approval-token + plan errors stops drifting from the runtime — they previously reused `SandboxError` which advertises the read-side `GET, OPTIONS` Allow-Methods and omits the explicit `Allow-Credentials: false` write-side guarantee. The execute route uses `SandboxExecuteError` instead because it ships reliability fields (`execution_guarantee` + `outcome`) that approval-token + plan do NOT emit.
- `413`: Sandbox 4xx / 5xx error from a write-side endpoint (`/api/v1/sandbox/auth/approval-token`, `/api/v1/sandbox/actions/plan`). Body shape mirrors `SandboxError` (the read-side error envelope) but the response carries the write-side CORS contract that `applySandboxWriteSideCorsHeaders` stamps on every error path: `Access-Control-Allow-Methods: POST, OPTIONS`, `Access-Control-Allow-Credentials: false`, and the write-side `Access-Control-Allow-Headers` safe list. Introduced so the published contract for approval-token + plan errors stops drifting from the runtime — they previously reused `SandboxError` which advertises the read-side `GET, OPTIONS` Allow-Methods and omits the explicit `Allow-Credentials: false` write-side guarantee. The execute route uses `SandboxExecuteError` instead because it ships reliability fields (`execution_guarantee` + `outcome`) that approval-token + plan do NOT emit.
- `422`: Sandbox 4xx / 5xx error from a write-side endpoint (`/api/v1/sandbox/auth/approval-token`, `/api/v1/sandbox/actions/plan`). Body shape mirrors `SandboxError` (the read-side error envelope) but the response carries the write-side CORS contract that `applySandboxWriteSideCorsHeaders` stamps on every error path: `Access-Control-Allow-Methods: POST, OPTIONS`, `Access-Control-Allow-Credentials: false`, and the write-side `Access-Control-Allow-Headers` safe list. Introduced so the published contract for approval-token + plan errors stops drifting from the runtime — they previously reused `SandboxError` which advertises the read-side `GET, OPTIONS` Allow-Methods and omits the explicit `Allow-Credentials: false` write-side guarantee. The execute route uses `SandboxExecuteError` instead because it ships reliability fields (`execution_guarantee` + `outcome`) that approval-token + plan do NOT emit.
- `429`: Sandbox 4xx / 5xx error from a write-side endpoint (`/api/v1/sandbox/auth/approval-token`, `/api/v1/sandbox/actions/plan`). Body shape mirrors `SandboxError` (the read-side error envelope) but the response carries the write-side CORS contract that `applySandboxWriteSideCorsHeaders` stamps on every error path: `Access-Control-Allow-Methods: POST, OPTIONS`, `Access-Control-Allow-Credentials: false`, and the write-side `Access-Control-Allow-Headers` safe list. Introduced so the published contract for approval-token + plan errors stops drifting from the runtime — they previously reused `SandboxError` which advertises the read-side `GET, OPTIONS` Allow-Methods and omits the explicit `Allow-Credentials: false` write-side guarantee. The execute route uses `SandboxExecuteError` instead because it ships reliability fields (`execution_guarantee` + `outcome`) that approval-token + plan do NOT emit.
- `500`: Sandbox 4xx / 5xx error from a write-side endpoint (`/api/v1/sandbox/auth/approval-token`, `/api/v1/sandbox/actions/plan`). Body shape mirrors `SandboxError` (the read-side error envelope) but the response carries the write-side CORS contract that `applySandboxWriteSideCorsHeaders` stamps on every error path: `Access-Control-Allow-Methods: POST, OPTIONS`, `Access-Control-Allow-Credentials: false`, and the write-side `Access-Control-Allow-Headers` safe list. Introduced so the published contract for approval-token + plan errors stops drifting from the runtime — they previously reused `SandboxError` which advertises the read-side `GET, OPTIONS` Allow-Methods and omits the explicit `Allow-Credentials: false` write-side guarantee. The execute route uses `SandboxExecuteError` instead because it ships reliability fields (`execution_guarantee` + `outcome`) that approval-token + plan do NOT emit.
- `502`: Sandbox 4xx / 5xx error from a write-side endpoint (`/api/v1/sandbox/auth/approval-token`, `/api/v1/sandbox/actions/plan`). Body shape mirrors `SandboxError` (the read-side error envelope) but the response carries the write-side CORS contract that `applySandboxWriteSideCorsHeaders` stamps on every error path: `Access-Control-Allow-Methods: POST, OPTIONS`, `Access-Control-Allow-Credentials: false`, and the write-side `Access-Control-Allow-Headers` safe list. Introduced so the published contract for approval-token + plan errors stops drifting from the runtime — they previously reused `SandboxError` which advertises the read-side `GET, OPTIONS` Allow-Methods and omits the explicit `Allow-Credentials: false` write-side guarantee. The execute route uses `SandboxExecuteError` instead because it ships reliability fields (`execution_guarantee` + `outcome`) that approval-token + plan do NOT emit.
- `504`: Sandbox 4xx / 5xx error from a write-side endpoint (`/api/v1/sandbox/auth/approval-token`, `/api/v1/sandbox/actions/plan`). Body shape mirrors `SandboxError` (the read-side error envelope) but the response carries the write-side CORS contract that `applySandboxWriteSideCorsHeaders` stamps on every error path: `Access-Control-Allow-Methods: POST, OPTIONS`, `Access-Control-Allow-Credentials: false`, and the write-side `Access-Control-Allow-Headers` safe list. Introduced so the published contract for approval-token + plan errors stops drifting from the runtime — they previously reused `SandboxError` which advertises the read-side `GET, OPTIONS` Allow-Methods and omits the explicit `Allow-Credentials: false` write-side guarantee. The execute route uses `SandboxExecuteError` instead because it ships reliability fields (`execution_guarantee` + `outcome`) that approval-token + plan do NOT emit.

---

[API](https://skmtc.dev/apier/apis/apier-no-api.md) · [All operations](https://skmtc.dev/apier/apis/apier-no-api/llms.txt) · [OpenAPI document](https://skmtc.dev/apier/apis/apier-no-api/revisions/9ec19bc87311?raw)