How it works
A CI job starts a suite over the API, keeps the batch id from the response, then polls that batch until every run is finished.Start the run
POST /api/suites/{id}/run schedules one run for each scenario of the suite:
batchRunId addresses the batch. jobCount is the number of runs the batch gets.
Poll the batch
GET /api/simulation-runs/batches/{batchRunId} answers with the counts of one batch:
Stop the poll when
isComplete is true and totalCount is at least jobCount. The two conditions go together: the platform creates the runs asynchronously, so a batch read right after the trigger can hold fewer runs than jobCount, and a batch of two created runs out of six reports itself complete.
The same asynchronous creation makes the first read answer 404. The batch becomes readable when its first run is stored, which is a moment after the trigger returns. Treat a 404 as “not stored yet” and poll again until your own timeout expires. A 404 is a missing batch only after that timeout.
Every other status stops the job at once. A wrong token answers 401 and a failed read answers 5xx, and a loop that polls through them reports a batch timeout thirty minutes later for a fault that was clear on the first read.
Exit the CI job nonzero when failCount is above zero or stalledCount is above zero. A stalled run settles without passing, so it counts in settledCount but not in failCount, and a job that reads failCount alone reports success for a batch that never finished its work. Open the batch in the platform for the run details.