Skip to main content
Replay a fixture prompt through the routing engine twice — once with the preference disabled (baseline) and once with it applied — so you can see exactly what your tuning would change before saving. Two routes share the same response shape:
  • POST /api/v1/routing-preferences/{id}/test — replay against a saved preference.
  • POST /api/v1/routing-preferences/test — replay against an unsaved draft body (no DB writes). Used by the dashboard test bench on every keystroke.

Authentication

Requires a Bearer token with the billing API key scope.

Saved-preference body

string
required
Prompt to replay. Up to 4096 chars.
string
required
Caller mode to simulate (e.g. "auto", "fast", "think").

Draft body

string
required
Prompt to replay. Up to 4096 chars.
string
required
Caller mode to simulate.
object
required
Unsaved preference envelope. Same shape as a create body minus scope and is_default. Fields: name, optional description, rules, examples, confidence_floor_overrides. Validated for brand safety + regex compile + vendor-name scrubbing identically to the persisted routes.

Request Examples

Response

Both routes return the same shape. Each blob matches the routing telemetry your callers receive on a real completion.

Errors

  • 400 routing_preference_invalid — Draft validation failure (vendor name, uncompilable regex, etc.).
  • 404 not_found — Saved preference doesn’t exist or isn’t visible to the caller.