Save Test Case definitions, scripts, Test Runs, and change history as JSON for reporting or an integration. Use readable Test Case keys and version numbers to keep definitions and executions together.

Endpoints

Action	Method	Endpoint
Retrieve Test Case definitions	GET	`/api/v2/testCases`
Retrieve test scripts	GET	`/api/v2/testCase/list/testScripts`
Retrieve individual Test Runs	GET	`/api/v2/runs`
Retrieve a run’s execution details	GET	`/api/v2/run/{runIdentifier}/details`
Retrieve a run’s change history	GET	`/api/v2/run/{runIdentifier}/history`
Retrieve a Test Case’s change history	GET	`/api/v2/testCase/{caseKey}/history`

Add each endpoint path to your Vansah base URL. Replace {caseKey} with a readable key, such as DEMO-C46. For run details and history, use the testRunIdentifier returned in Step 3; those two endpoints require that value.

Before you begin

These examples use Bash and cURL. Set VANSAH_URL to your Vansah base URL without a trailing slash and VANSAH_TOKEN to your Vansah API token. Send the token directly in the Authorization header, without a Bearer prefix. Keep it private.

The token account must be able to access the Jira space and testing data. Replace DEMO with your Jira space key. The API parameter projectKey and JSON path project.key refer to the Jira space key.

The examples use Bash and cURL. Run them from a directory where you can save the output files. Every request below uses GET and has no JSON request body.

1. Save the Test Case definitions

Endpoint: GET /api/v2/testCases

curl --request GET --get \
  --url "$VANSAH_URL/api/v2/testCases" \
  --header "Authorization: $VANSAH_TOKEN" \
  --header "Accept: application/json" \
  --data-urlencode "projectKey=DEMO" \
  --data-urlencode "startAt=0" \
  --data-urlencode "limit=50" \
  --data-urlencode "sortBy=caseKey" \
  --data-urlencode "sortOrder=asc" \
  --output test-cases-0.json

Example HTTP 200 response excerpt with selected fields:

{
  "success": true,
  "message": "Test Cases returned successfully",
  "data": {
    "pagination": {
      "total": 1,
      "startAt": 0,
      "limit": 50
    },
    "data": [
      {
        "caseKey": "DEMO-C46",
        "testCaseVersion": 1,
        "headline": "Sign in with a valid account"
      }
    ]
  }
}

Keep the caseKey and testCaseVersion from each row. A space-wide request uses each case’s current default version. A request scoped to a work item or Test Folder uses the version linked to that context. See List Test Cases for filters and version behavior.

Query parameter	Example value	Use
projectKey	`DEMO`	Your Jira space key.
startAt	`0`	Offset. Defaults to 0.
limit	`50`	Page size. Defaults to 50. Use a positive whole number.
sortBy	`caseKey`	Sort by the Test Case number.
sortOrder	`asc`	Keep a consistent order across pages.

2. Save the scripts for each case and version

Endpoint: GET /api/v2/testCase/list/testScripts

Use the readable key and version from the definition you are exporting:

curl --request GET --get \
  --url "$VANSAH_URL/api/v2/testCase/list/testScripts" \
  --header "Authorization: $VANSAH_TOKEN" \
  --header "Accept: application/json" \
  --data-urlencode "caseKey=DEMO-C46" \
  --data-urlencode "testCaseVersion=1" \
  --output demo-c46-version-1-scripts.json

Query parameter	Example value	Use
caseKey	`DEMO-C46`	Required. One readable Test Case key, or comma-separated keys with no spaces. Each case must be active and associated with your token account’s accessible Jira spaces.
testCaseVersion	`1`	The existing case version to retrieve. Use the version returned with the definition. If omitted, the current default version is read.
type	`steps`	Optional: steps, plainText, bdd, or automation. Omit it to return the applicable script formats.

The HTTP 200 response has success: true, message Test Scripts returned successfully, and a data object containing the applicable steps, plainText, bdd, or automation arrays.

Example response excerpt for a case with a Multi Steps script:

{
  "success": true,
  "message": "Test Scripts returned successfully",
  "data": {
    "steps": [
      {
        "stepOrder": 1,
        "plainStep": "Sign in with a valid account",
        "plainExpectedResult": "The account dashboard opens",
        "plainTestData": "Use a synthetic test account"
      }
    ]
  }
}

This endpoint does not paginate with startAt or limit. Request one case/version at a time, or use small batches sharing the same requested version. To preserve a historical execution, request that run’s case version rather than assuming the current definition matches it.

3. Save the individual Test Runs

Endpoint: GET /api/v2/runs

curl --request GET --get \
  --url "$VANSAH_URL/api/v2/runs" \
  --header "Authorization: $VANSAH_TOKEN" \
  --header "Accept: application/json" \
  --data-urlencode "projectKey=DEMO" \
  --data-urlencode "format=detail" \
  --data-urlencode "type=testCaseRuns" \
  --data-urlencode "startAt=0" \
  --data-urlencode "limit=50" \
  --data-urlencode "sortBy=testedDate" \
  --data-urlencode "sortOrder=asc" \
  --output test-runs-0.json

Example HTTP 200 response excerpt:

{
  "success": true,
  "pagination": {
    "total": 1,
    "startAt": 0,
    "limit": 50
  },
  "data": [
    {
      "projectKey": "DEMO",
      "caseKey": "DEMO-C46",
      "testRunKey": 248,
      "testRunIdentifier": "22222222-2222-4222-8222-222222222222",
      "testCaseVersion": 1,
      "resultName": "PASSED"
    }
  ]
}

Query parameter	Example value	Use
projectKey	`DEMO`	Your Jira space key.
format	`detail`	Required for this workflow. Returns rows and pagination.
type	`testCaseRuns`	Returns individual executions, including Test Plan executions. Keep this value when exporting runs.
startAt	`0`	Offset. Defaults to 0.
limit	`50`	Page size. Defaults to 50. Use a positive whole number.
sortBy	`testedDate`	Sort by the run’s last edited time, with run order as a tie-breaker.
sortOrder	`asc`	Ascending order.
caseKey	`DEMO-C46`	Optional: limit the export to one readable Test Case key.
testCaseVersion	`1`	Optional: limit executions to a specific case version.

Keep each returned testRunIdentifier for the next step. The full rows also include execution context, timestamps, results, and environment, release, and sprint names. testRunKey is the run number, not the value used by the details and history endpoints.

4. Save execution details for each run

Endpoint: GET /api/v2/run/{runIdentifier}/details

Copy testRunIdentifier from the matching row in Step 3. Set RUN_IDENTIFIER to your returned value; the value below is synthetic:

RUN_IDENTIFIER="22222222-2222-4222-8222-222222222222"

curl --request GET --get \
  --url "$VANSAH_URL/api/v2/run/$RUN_IDENTIFIER/details" \
  --header "Authorization: $VANSAH_TOKEN" \
  --header "Accept: application/json" \
  --data-urlencode "autoCreateLogs=0" \
  --data-urlencode "iterationNumber=1" \
  --output run-details-iteration-1.json

Query parameter	Example value	Use
autoCreateLogs	`0`	Keep 0 for an export so this request does not create missing execution logs.
iterationNumber	`1`	Positive Test Data Collection iteration number. Defaults to 1. It does not select a different Test Plan iteration.

HTTP 200 returns message Run returned successfully. and the execution object at JSON path data.run. Its logs array contains saved step results, actual results, and related evidence entries.

For runs with Test Data Collection iterations, read JSON path data.run.iteration.nums. Repeat the details request for each returned number, changing iterationNumber and the output filename. JSON path data.run.iteration.selected identifies the iteration returned.

5. Save change history

Endpoint: GET /api/v2/run/{runIdentifier}/history

Retrieve the selected run’s change history using the same value copied in Step 4:

curl --request GET --get \
  --url "$VANSAH_URL/api/v2/run/$RUN_IDENTIFIER/history" \
  --header "Authorization: $VANSAH_TOKEN" \
  --header "Accept: application/json" \
  --data-urlencode "sortOrder=ASC" \
  --output run-history.json

HTTP 200 returns message Test Run History returned successfully. and the history array at JSON path data.run.

Endpoint: GET /api/v2/testCase/{caseKey}/history

Retrieve a Test Case’s change history using its readable key:

curl --request GET --get \
  --url "$VANSAH_URL/api/v2/testCase/DEMO-C46/history" \
  --header "Authorization: $VANSAH_TOKEN" \
  --header "Accept: application/json" \
  --data-urlencode "sortOrder=ASC" \
  --output demo-c46-history.json

HTTP 200 returns message Test Case History returned successfully. and the history array at JSON path data. These are change entries, separate from the individual execution rows exported in Step 3.

Both history requests use sortOrder=ASC for oldest first or DESC for newest first. The default is DESC. History responses do not paginate with startAt or limit.

Retrieve every page

Request	Records — JSON path	Pagination — JSON path
`GET /api/v2/testCases`	`data.data`	`data.pagination`
`GET /api/v2/runs`	`data`	`pagination`

Repeat each list request with startAt=50, then 100, keeping its other options unchanged. Save each page to a different filename. Both lists default to 50 records; neither validator defines a maximum page size.

Check success before processing a page. Stop when you have retrieved the matching count or the record array is empty. An empty page can report total 0 even if earlier pages had records.

Records can move between pages if data changes during the export. Check for duplicate case keys/versions and run identifiers, and reconcile counts afterward.

Check and store the exported files

Match each execution to its Test Case key and version. Keep original JSON alongside any CSV or reporting tables so nested fields remain available. The JSON contains only the data returned by these requests; it is not a complete restorable backup.

Attachment entries and links are references to files. Saving JSON does not download the attachment contents. Run details can also contain test data and variable values; store your exported files with the access controls appropriate for that data.

Troubleshooting

HTTP status or issue	What to check
`400` — validation errors	Inspect JSON path data.errors. For runs, include format=detail and type=testCaseRuns. Check version, sort, and paging values.
`400` — `Invalid case key(...)`	Use an active case’s readable key and confirm the token account’s access to its Jira space.
`400` — `Test Run not found.`	Use testRunIdentifier from Step 3. The details and history paths require that value, and the run must be active in this workspace.
`400` — `Test Case not found.`	Use the exact readable case key, such as DEMO-C46, and confirm space access.
`400` — `Iteration number exceeds the total iterations.`	Use a number returned at data.run.iteration.nums.
`401` — authentication failed	Check the raw Vansah API token, expiry, connected Jira access, and copied base URL.
`403` — account blocked	Ask your administrator to review the account’s Vansah access.
Only 50 cases or runs were saved	Retrieve the remaining pages using startAt and limit.
Scripts or history do not match a run	Use the execution’s testCaseVersion and save the corresponding script version. Change history and execution history serve different purposes.

If a request fails, retain its HTTP status and JSON message. Share the request path and error with Vansah Support without your token or customer data.

Export Test Cases and Test Runs with the API