---
title: "Sandbox plan describing the prerequisite chain (API key or sandbox bearer)"
method: POST
path: "/api/v1/sandbox/actions/plan"
tags: ["Sandbox"]
---

# Sandbox plan describing the prerequisite chain (API key or sandbox bearer)

`POST /api/v1/sandbox/actions/plan`

## Request

- Base URL: `https://www.apier.no`
- URL: `https://www.apier.no/api/v1/sandbox/actions/plan`
- Auth: one of:
  - HTTP bearer
  - HTTP bearer

Returns the deterministic prerequisite chain for executing a regulatory action. Plan describes 5 steps in order: verify_company → verify_delegation → validate_payload → mint_approval_token → execute. Sandbox plan is its own contract — there is NO production `/api/v1/actions/plan` endpoint to mirror today. introduced this surface so 's full chain can run end-to-end on sandbox.

Plan does NOT emit the approval token directly — call `/api/v1/sandbox/auth/approval-token` after plan. The plan response includes `mint_endpoint` (the URL to call next) and `requires_approval` (boolean). These field names deliberately AVOID the substring `token` because the integration suite's secret-scanner walks every response key against `/token|secret|password|key_hash|api_key/i` — using `requires_approval_token` / `approval_token_endpoint` would have triggered false positives on a deterministic metadata field.

## 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

- `Idempotency-Key` string
- `X-Correlation-ID` string, uuid

## Request body

- object
  - `org_number` string, required: 9-digit reserved synthetic org. Must appear in the `data.sandbox.reserved_test_org_numbers` array on the response body of `GET /api/v1/capabilities` (or 999000901-904 for reserved error orgs). Any other 9-digit value returns 400 VALIDATION_FAILED — distinct from the read-side which 404s on unknown orgs (sandbox write-side invariant).
  - `action` 'mva_melding' | 'a_melding', required

## Response `200`

Plan returned. Each step has `step` (machine-readable id), `status` (`ok` for prerequisites already satisfied, `pending` for what the agent must do next), and `description_nb` (Norwegian bokmål prose).

- object
  - `success` unknown, required
  - `data` object, required
    - `org_number` string, required
    - `action` string, required
    - `plan` object[], required: Five-element tuple, fixed order: verify_company → verify_delegation → validate_payload → mint_approval_token → execute. Pinned to a JSON Schema 2020-12 `prefixItems` tuple with `minItems: 5` + `maxItems: 5` + per-step `step: { const: ... }` so the published contract matches the runtime invariant. SDK consumers can switch on positional index; type generators emit a tuple type.
    - `requires_approval` boolean, required: Always true today — every action sandbox supports requires an approval token before live execute. Field name deliberately omits `token` substring (secret-scanner avoidance).
    - `mint_endpoint` string, required: URL of the approval-token mint endpoint (`/api/v1/sandbox/auth/approval-token`). Field name deliberately omits `token` substring (secret-scanner avoidance).
  - `_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.
- `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.

---

[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)