The Test Run REST API should provide the PreCondition details

Description

The Xray Server/Data Center REST API endpoint, does not expose the preconditions associated with a Test Run, even though Xray documentation states that Test Runs store Pre-Condition details. 

GET  /rest/raven/2.0/api/testrun/{testRunId} 

The same information appears to be available in Xray Cloud through the GraphQL API and is also accessible through Document Generator variables such as 

${TestRuns[n].PreConditions[p].Conditions}.

This creates an inconsistency between API capabilities and the data model documented by Xray.

User friction

Users cannot programmatically retrieve precondition information associated with a test execution run, forcing them to rely on indirect methods, additional Jira queries, or document generation features to access data that is already stored within the Test Run.

Steps to reproduce (right now) / Actual Result:

• Create a Test with one or more Preconditions.
• Execute the Test and create a Test Run.
• Execute the ResT API call:

GET {jiraServer}/rest/raven/2.0/api/testrun/{testRunId}

• Review the response payload.

 
Actual Result: The response contains step execution information and other Test Run data, but does not include the Preconditions associated with the Test Run.
 

Expected Result: The API response in Server/DC should include the Preconditions stored within the Test Run, similar to:

• Information available through Document Generator variables.
• Information exposed through the Xray Cloud GraphQL Test Run schema.

IMPACT

Integrations that depend on complete Test Run information cannot retrieve Preconditions through the REST API. This limits reporting, traceability, audit capabilities, and synchronization with external QA and compliance systems.

What would improve if solved:

• Full Test Run data could be retrieved through a single API call.
• Better alignment between Server/Data Center and Cloud capabilities.
• Reduced need for additional Jira lookups and custom correlation logic.
• Easier integration with reporting, compliance, and automation tools.

Impact on stakeholders:

• QA Engineers: Improved automated reporting and traceability.
• Test Managers: Better visibility into execution context and validation criteria.
• Integration Developers: Simpler API integrations and reduced implementation complexity.
• Compliance/Audit Teams: Access to complete execution evidence and requirements validation.

Current workaround:
Retrieve Preconditions from the Test issue itself through separate API calls and manually map them to the Test Run, or generate reports using the Document Generator where the information is available.

CONTEXT & EXAMPLES:
According to Xray documentation, Test Runs store Pre-Condition details. Additionally:

• Document Generator supports access to Test Run Preconditions through variables such as:

${TestRuns[n].PreConditions[p].Conditions}

• Xray Cloud GraphQL APIs expose Precondition information on Test Runs.

This suggests the information exists within the Test Run model but is not currently exposed by the Server/Data Center REST API.

Concrete example:
A team exports Test Execution results to a third-party reporting system. The REST API provides test steps and execution status but omits Preconditions. As a result, the external report lacks critical execution prerequisites and validation context, despite that information being present within Xray and available through Document Generator templates.
Workaround risk:

• Additional API calls increase implementation complexity and maintenance effort.
• Manual correlation between Tests and Test Runs may become inaccurate if Preconditions change over time.
• Integrations may not reflect the exact Precondition state captured when the Test Run was executed.
• Increased API traffic and reduced performance for large-scale reporting solutions.