Skip to main content
A sandbox fixture makes a run finish in a state you choose: completed, degraded or failed. The run goes through normal admission, polling and webhooks, but its output comes from a published fixture file and no model or enrichment provider is called. Use it to test that your client handles every terminal state.
Fixtures work only for the fixture engine, generic_fixture_engine, at the exact versions in the supported contract registry: 1.0, 1.1, 1.3 and 2.0. Your own engines cannot run fixtures. A request against any other engine or version gets 400 test_scenario_version_not_supported.

Requirements

Ask Nexio for a fixture testing key if you need one.

Request

Add test_scenario at the top level of a run request, next to input:
The engine slug in your org is set when Nexio creates the fixture engine for you; generic-fixture-engine above is an example. Response 202:

Outcomes

The run’s output, warning_details, error and error_details are the values in the entry’s fixture file under terminal.completed, terminal.degraded or terminal.failed. For version 1.0, a failed fixture run reports:
test_scenario is never inferred from input, and it does not appear in poll or webhook responses.

What still applies

  • Each fixture run is a real run: it counts against the monthly run cap and the rate limits.
  • Idempotency-Key works as for any run, and test_scenario is part of the request it compares.
  • Webhook secret rotation in a sandbox keeps the previous secret valid for 5 minutes.

Errors

Checks run in this order, and a refused request creates no run, uses no cap and queues nothing.
Last modified on September 25, 2026