create_test_results_bulk
Record new test executions for several cases in one test run with a single call, returning created execution ids aligned to the input entries.
Instructions
Record NEW executions for several items of ONE test run in a single call (POST /testrun/{runKey}/testresults). The body is the results array itself; in each entry only the fields you pass are sent, and the returned ids are positionally aligned with it. The test case should already be an item of the run; if it is not, the behavior is VERSION-SPECIFIC — some Server builds silently ADD it to the run as a new item (verified live: testCaseCount grows; the new item's POSITION in items[] is not the head and not the tail — it landed second of three and second of four in two separate runs, so do not rely on where it appears), others reject the call with 400/404. Default statuses: 'Not Executed', 'In Progress', 'Pass', 'Fail', 'Blocked' — case-sensitive internal names; instances may define custom ones. scriptResults carry per-step outcomes of a STEP_BY_STEP script as { index (0-based), status, comment? }. An overall status sent TOGETHER with scriptResults is stored as sent (verified live: 'Blocked' with three 'Pass' steps stored 'Blocked') and is NEVER derived from the step statuses — scriptResults without a status leave the execution at the project default ('Not Executed'), so pass status in the SAME call. Some older builds may instead ignore the overall status: read the result back with get_test_run_results rather than sending a second update_last_test_result, which replaces the whole execution. A scriptResults entry whose index is past the last step of the case is discarded silently (HTTP 200, no error). matchEnvironment / matchUserKey apply to the WHOLE batch and only SELECT which existing run item to append to — they never set the created result's environment. NOT ATOMIC, and it does NOT abort at the failing entry: when one entry is rejected (unknown testCaseKey, bad status/iteration/version value, unknown custom field) the call answers an error and returns no ids, yet that entry alone is SKIPPED while EVERY other valid entry is COMMITTED — the entries AFTER the failing one just as much as those before it (verified live twice, with ids: [valid, valid, unknown key, valid] committed entries 1, 2 and 4; [unknown key, valid] committed entry 2). So after an error that names ONE entry the batch may already be fully written except for that entry: re-read the run with get_test_run_results BEFORE resending anything and resend only the entries that are genuinely missing — resending the batch or its tail creates DUPLICATE executions. An error that rejects the payload as a whole (a malformed body, an unknown run key, a batch-wide matchEnvironment/matchUserKey the API cannot resolve) is different: it is refused before any entry is processed, so nothing was committed and nothing needs re-reading. Two entries for the same test case create two independent executions (no upsert). Returns the array of created executions ([{ id }, …]).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| results | Yes | One entry per execution to record; each targets a run item by testCaseKey and carries that execution's fields | |
| testRunKey | Yes | Test run (cycle) key, e.g. PROJ-R123 (PROJ-C123 on older instances) | |
| matchUserKey | No | Run-item selector, sent as the 'userKey' QUERY parameter (never in the body): targets the run item by its executor's Jira user key, e.g. 'JIRAUSER10000'. | |
| matchEnvironment | No | Run-item selector, sent as the 'environment' QUERY parameter (never in the body): targets the run item with this environment (case-sensitive). Distinct from the 'environment' body field, which sets the environment recorded on the result. |