Start Performance Test
Kick off a paced load test.
Hitting this endpoint — not a flag on /api/initiatecall — is what tells
the backend to treat the resulting calls as load-test traffic. The
response returns immediately with a `perf_test_run_id`; the actual
dialing happens in a background task.
Authorizations
Basic authentication header of the form Basic <encoded-value>, where <encoded-value> is the base64-encoded string username:password.
Body
application/jsonProject ID to run the perf test against
ID of the suite the test was launched from. When set, the orchestrator reads scenarios + matrix from this suite and ignores `scenario_ids / scenarios / iterations`.
Total number of dials to place when `source_suite_id` is set. Distributed round-robin across the suite's combos at a fixed 5 calls-per-second pacing rate.
Scenario IDs to expand and dial. Required when `source_suite_id` is not set.
Per-scenario overrides (voice / phone number / matrix axes). Same shape used by /api/initiatecall — keeps matrix expansion behavior identical between live and load-test runs.
Optional suite name for the auto-created perf suite. Defaults to `perf-test-{profile}-{run_id_prefix}` if unset.
Pacing pattern: ramp_up | sustained | spike
Peak concurrent calls the orchestrator is allowed to drive. The org's `max_inbound_parallel_calls` is temporarily raised to at least this value for the run, then restored.
Calls added per ramp step (ramp_up profile only).
Seconds to wait between ramp steps before adding more load. Set to 0 when pacing is driven entirely by `cooldown_between_calls_ms` (e.g. when scheduling a fixed calls-per-second rate).
How long to hold max_concurrency once reached (sustained / spike).
Milliseconds to stagger individual dials within a single step so provider create-call requests don't arrive simultaneously.
Response
application/jsonSuccessful Response
Pacing pattern the orchestrator applies to the call list.