---
title: "Sandbox mirror of /api/v1/auth/approval-token (API key or sandbox bearer)"
method: POST
path: "/api/v1/sandbox/auth/approval-token"
tags: ["Sandbox"]
---

# Sandbox mirror of /api/v1/auth/approval-token (API key or sandbox bearer)

`POST /api/v1/sandbox/auth/approval-token`

## Request

- Base URL: `https://www.apier.no`
- URL: `https://www.apier.no/api/v1/sandbox/auth/approval-token`
- Auth: one of:
  - HTTP bearer
  - HTTP bearer

Zero-auth deterministic mint of a sandbox-scoped approval token bound to (org_number, action). The returned token is exactly 49 characters: 17-char `sandbox-approval-` prefix + 32-char lowercase-hex HMAC-SHA-256 suffix. Same input → same token, every time. Production approval-token validators MUST treat any token bearing this prefix as invalid in production code paths.

`expires_at` is INFORMATIONAL ONLY — sandbox /actions/execute does NOT enforce it against wall-clock time (sandbox is deterministic-by-construction; expires_at is metadata for the agent's UI). Sandbox does not write to the production `approval_tokens` table — there is no DB row backing the returned token. The token is purely an HMAC-derived string.

The HMAC secret used here is `SANDBOX_RECEIPT_HMAC_KEY` (env var, REQUIRED when `VERCEL_ENV=production`; falls back to a known-public dev literal in non-production environments). `SANDBOX_RECEIPT_HMAC_KEY` is by design fully separable from the production `RECEIPT_HMAC_SECRET` — sandbox tokens cannot be cross-verified as production receipts and vice versa.

## 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: Closed enum mirroring production `/api/v1/actions/execute`'s ActionTypeEnum.

## Response `200`

Token minted. `data.approval_token` is the 49-char string the agent passes to /api/v1/sandbox/actions/execute via the body's `approval_token` field.

- object
  - `success` unknown, required
  - `data` object, required
    - `approval_token` string, required
    - `expires_at` string, date-time, required: 5 min from SANDBOX_NOW (deterministic). Informational only; /actions/execute does NOT enforce expires_at.
    - `scope` object, required
      - `org_number` string, required
      - `action` string, 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.
- `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)