Skip to main content
Production keys are issued only after every checklist item passes in the sandbox. This page lists what Vort provides for that, and the fixtures you build and test against. RFC 2119 keywords apply.

What Vort provides

  • A sandbox partner key and a sandbox customer organization with credits.
  • An activation code for that organization, plus an expired one and an already-redeemed one.
  • Synthetic jobs whose runs return a fixed, known payload (the fixtures below).
  • A requirements set that triggers every rejection code and every warning code (see Requirement validation examples).
  • A signed test webhook for each event, and one webhook with a bad signature (see Test webhooks).

How fixtures work

A POST /runs whose job_external_id starts with cert- never runs the engine. It returns immediately with a deterministic payload you can build and test against. You do not have to create the job first (POST /jobs is optional for fixtures), and the cert- prefix is reserved in the sandbox: do not use it for your own jobs there.
Response
What still applies to a fixture run: the acting user must be registered (404 user_not_found), target_count must be 1 to 20, and any requirements you send are validated exactly as for a real run (so a fixture is a free place to test validation); the fixture’s own payload always uses its fixed requirement list, shown above. Then use the run_id like any other: GET /runs/{run_id}, reveal, decisions and notices_shown all work.
  • Fixture candidates have synthetic ids (990000000001, 990000000002, …) and obviously fake names (Test Candidate 1, or מועמד בדיקה 1 with x-vort-lang: he).
  • A fixture never lists more candidates than its target_count.
  • Fixture responses carry "sandbox": {"fixture": "<name>"}.
  • Notice title and body in fixtures are produced by the same code that writes them for real runs, in the language you request.
  • An unknown cert-* name answers 422 unknown_fixture with the valid names in fixtures.
  • Fixture runs do not count toward the sandbox’s daily run quota.

The fixtures

GET /runs/{run_id} returns: completed, up to 6 candidates with per-requirement met (true, false, null) and evidence (including null), and every notice code that a partner run can produce (9 of the 13), each in its catalogue slot: function_error, run_progress, location_relaxed, must_unmet_hidden, paid_fallback, already_shown, requirement_blockers (on its requirement, ref.requirement_index), requirement_attribution, run_funnel. All three severities appear. The other 4 codes cannot fire in v1 (see the notices catalogue); your generic renderer covers them.You MUST verify: every notice renders in its slot with its severity styling, title and body verbatim; warning and blocking have no dismiss control (C-09). Candidate cards: verdict label, one row per requirement in index order, evidence verbatim, the fixed label for met: null (C-12).
GET /runs/{run_id} returns: completed, up to 3 candidates, and notices with the code zz_certification_probe: one per slot (above_list, on_candidate with ref.candidate_id, on_requirement with ref.requirement_index, empty_state) and severity (blocking, warning, info), plus one with the unknown slot zz_unknown_slot and one with the unknown severity zz_unknown_severity.You MUST verify: each probe renders generically from title + body; the unknown slot renders in above_list; the unknown severity renders as warning; nothing crashes, nothing is dropped (C-10). Report zz_certification_probe in notices_shown (C-16).
GET /runs/{run_id} returns: completed, zero candidates, empty_state notices only (run_progress, location_relaxed).You MUST verify: the empty_state notices replace the list; no “0 results” text of your own (C-11).
GET /runs/{run_id} returns: failed, zero candidates, one function_error notice (blocking, empty_state).You MUST verify: the progress indicator stops; the notice and the run_id are shown (C-07, C-11).
GET /runs/{run_id} returns: running for 3 minutes after creation, with progress.confirmed rising from 0 to target_count (and candidates appearing as they are confirmed) and a run_progress notice; then completed with all target_count candidates.You MUST verify: confirmed / target as numbers and a determinate bar that updates at least every 10 s; the final count replaces the indicator on completion (C-08).
GET /runs/{run_id} returns: completed, up to 3 candidates, and unknown fields everywhere: at the top level (zz_extra_top_level, zz_future_object), in progress, in every notice, every candidate, and every requirement (top-level and per candidate). The POST /runs, reveal and decisions responses of this run carry unknown top-level fields too.You MUST verify: the whole flow works with no error and no visible change (C-17).
GET /runs/{run_id} returns: completed immediately, up to 3 candidates. At creation a run_completed webhook is queued for this run (when your webhook is registered).You MUST verify: you receive run_completed for this run_id, verify its signature, answer 2xx, and then fetch GET /runs/{run_id} (C-18, C-19).

Reveals and decisions on fixtures

Only candidates currently listed on the run can be revealed (on cert-slow, the ones confirmed so far); decisions may name any candidate the fixture will ever list. Decisions are stored like production decisions and appear on Vort’s side for certification (C-15).