Upload a TestNG XML report to record results against existing Vansah Test Cases linked to Jira work items. The report needs Vansah mapping attributes; a standard report without those attributes is not sufficient.
Endpoint
Action | Method | Endpoint |
Import TestNG results | POST |
|
Append the path to your Vansah API Connect URL. The request uses multipart/form-data, not a JSON body.
Before you begin
Use a valid Vansah API token with Jira space access and the Vansah permission to import Test Case results.
Create the Test Cases and link them to the intended Jira work item before importing. This endpoint imports execution results; it does not create missing cases.
Use the exact custom-attribute structure below. Replace DEMO, case keys, and the work item key with your own Jira space values.
Keep the XML file within 25 MiB (26,214,400 bytes). Upload one file using testPaths.
Important: the current parser expects multiple test-method elements in each processed class. A class containing only one method can fail. It also maps status PASS to Passed and any other nonempty status—including SKIP—to Failed. Use this importer only for reports whose statuses you intend to map that way. Use Create a Test Run when you need explicit result control.
1. Prepare the XML report
Endpoint: POST /api/v2/testCase/import/XML
Save this synthetic example as testng-results.xml. It demonstrates two methods with separate case mappings. In your integration, arrange for the generated report to contain these mapping attributes.
<?xml version="1.0" encoding="UTF-8"?>
<testng-results>
<suite name="Checkout suite">
<test name="Checkout API">
<class name="example.CheckoutTests">
<test-method name="addProduct" status="PASS">
<custom-attributes>
<custom-attribute><name value="Case Key"/><value>DEMO-C46</value></custom-attribute>
<custom-attribute><name value="Tested Issue"/><value>DEMO-123</value></custom-attribute>
</custom-attributes>
</test-method>
<test-method name="removeProduct" status="FAIL">
<custom-attributes>
<custom-attribute><name value="Case Key"/><value>DEMO-C47</value></custom-attribute>
<custom-attribute><name value="Tested Issue"/><value>DEMO-123</value></custom-attribute>
</custom-attributes>
</test-method>
</class>
</test>
</suite>
</testng-results>
XML value | Required? | Meaning |
| Yes, for an imported method | Existing readable Test Case key, such as DEMO-C46. |
| Yes, for an imported method | Existing linked Jira work item key, such as DEMO-123. |
| Optional | Environment name. |
| Optional | Existing Jira sprint name. |
| Optional | Existing Jira release version name; not a Test Case version. |
The attribute names and nested name value="..." / value structure must match the example. A method without custom attributes is skipped by the XML conversion. A method with custom attributes but missing Case Key or Tested Issue causes a validation error.
Only the mapping, status, and listed property names are extracted from this XML path. TestNG stack traces, screenshots, test timestamps, durations, and individual assertion details are not imported by this mapping.
2. Upload the report
Endpoint: POST /api/v2/testCase/import/XML
These examples use Bash and cURL. Set VANSAH_URL to your base URL without a trailing slash and VANSAH_TOKEN to your private token. Send the token directly without a Bearer prefix.
curl --request POST \
--url "$VANSAH_URL/api/v2/testCase/import/XML?projectKey=DEMO" \
--header "Authorization: $VANSAH_TOKEN" \
--header "Accept: application/json" \
--form "testFormat=TestNG" \
--form "[email protected];type=application/xml"
Location | Field | Value / use |
Query |
| Your Jira space key. The API retains this literal parameter name. |
Form text |
| Required. Use TestNG (matched without case sensitivity). |
Form file |
| Required XML report file. This is an upload, not a server path string. |
Let cURL set the multipart Content-Type boundary. In Postman, use form-data, set testFormat to text and testPaths to File, and include projectKey as a query parameter.
3. Inspect the response
Endpoint: POST /api/v2/testCase/import/XML
A completed request returns HTTP 200 with success: true, but some rows may still have failed. Inspect succeedRows, failedRows, totalRows, and the per-row logs. The total counts converted XML rows, not necessarily every method in the report.
Example response excerpt showing the summary fields; the full data object also contains importLogs and failedLogs arrays:
{
"success": true,
"message": "Results import is completed.",
"data": {
"failedRows": 0,
"succeedRows": 2,
"totalRows": 2
}
}
Open the linked cases in Vansah and verify their runs and results. Each imported row creates a new run. Check what saved before retrying a timeout or partial import.
Errors and limitations
Outcome | What to check |
HTTP 400 / invalid input | testFormat, uploaded file, XML structure, mappings, case/work item existence, and supported workspace result names. Validation errors can appear in data.errors. |
HTTP 401 | Token validity and the account’s Atlassian connection. |
HTTP 403 | Jira space access and import permission. Permission lookup failures can return HTTP 503. |
Failed rows in HTTP 200 | Read failedLogs and verify the case is linked to the tested work item. |
Failed to validate XML | Check the current single-method limitation and the expected custom-attribute structure. |
Missing properties | Use exact existing release/sprint names and verify the saved run. Unmatched optional properties can remain unset. |
The XML path does not extract Test Plan keys or iterations. Use the appropriate plan API guide for plan executions. It does not preserve the original TestNG tester or execution time; imported runs use the importing account and import-time behavior.