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
APOST /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
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מועמד בדיקה 1withx-vort-lang: he). - A fixture never lists more candidates than its
target_count. - Fixture responses carry
"sandbox": {"fixture": "<name>"}. - Notice
titleandbodyin fixtures are produced by the same code that writes them for real runs, in the language you request. - An unknown
cert-*name answers422 unknown_fixturewith the valid names infixtures. - Fixture runs do not count toward the sandbox’s daily run quota.
The fixtures
cert-notices-all
cert-notices-all
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).cert-notice-unknown
cert-notice-unknown
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).cert-empty
cert-empty
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).cert-failed
cert-failed
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).cert-slow
cert-slow
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).cert-extra-fields
cert-extra-fields
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).cert-webhook
cert-webhook
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 (oncert-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).