The chat responses are generated using Generative AI technology for intuitive search and may not be entirely accurate. They are not intended as professional advice. For full details, including our use rights, privacy practices and potential export control restrictions, please refer to our Generative AI Service Terms of Use and Generative AI Service Privacy Information. As this is a test version, please let us know if something irritating comes up. Like you get recommended a chocolate fudge ice cream instead of an energy managing application. If that occurs, please use the feedback button in our contact form!
The Polarion REST API gives external applications an integration layer with Polarion that gives you greater control over the information you use in both Polarion and the applications you use daily.
You can update using PATCH via the resource URL. The resource URL is part of a request's body, and the resource's identification (type and ID) must match the resource described by the URL. The client can only update resources if it knows their URL and identification. (Typically by retrieving them using a GET request first.)
All fields are optional in PATCH requests.
The client only sends the fields (attributes and relationships) you want to update.
Warning
Treat multi-valued fields carefully. See the Update multi-valued fields section below for more information about updating multi-valued fields.
To update a field, you completely replace an old value with a provided value. This is especially important for multi-valued fields that contain a list of values. When you replace multi-valued fields, the old list of values is entirely replaced by the new list you provide.
If you want to add some values, you must provide a list containing all the old values and the new ones you want to add.
Add mTest to the list of Work Item Assignees that already contains sDeveloper¶
You can delete a single resource using DELETE via the resource URL. Deleting a single resource does not require any request body. Successful deletion of a resource results in an empty response with 204 - No Content status code.
You can delete multiple resources using DELETE via the resource collection URL. Deleting multiple resources at once requires a request body with the list of resource indentifications (Type and ID) you want to delete. Successful deletion of the resources results in an empty response with 204 - No Content status code.
Links between Work Items are represented by separate resources: linkedworkitems (direct links), backlinkedWorkItems, externallylinkedworkitems, and linkedoslcresources. The Work Item has a relationship to these resources. To fetch them, you can use the relationships endpoint. There are also separate endpoints to manage directly linked Work Items, externally linked Work Items, and OSLC links contained within a Work Item.
Work Item links are created by creating linkedworkitems resources. You do this by sending a POST request to the linkedworkitems endpoint of the source Work Item. Multiple links can be created at once.
To retrieve additional information about the links, or details about the linked Work Items, you must use the Work Item endpoint or the linked Work Items endpoint and a suitable combination of include and field query parameters.
Get a Work Item, its links, and linked Work Items in a single request¶
Example Request:
GET /polarion/rest/v1/projects/myProject/workitems/WI-1?include=linkedWorkItems,linkedWorkItems.workItem&fields[workitems]=title&fields[linkedworkitems]=@all
There are several REST API endpoints that allow you to work with attachments of various Polarion objects like Work Item attachments, Page attachments, or Document attachments. Among other uses, they allow you to modify attachment fields and upload or download their actual content.
When retrieving the attachment content via one of the content endpoints, keep in mind that the actual attachment content is returned "as is", corresponding to the original octet stream previously uploaded to Polarion via the User Interface or the API. Polarion does not perform any validation, sanitization, or malware or virus scan when uploading or downloading attachment files.
The following sections show examples of how to create and update Attachments. The examples are equally applicable to any of the supported Attachment types, including the following:
There are two ways to post Attachments: with or without using a local ID (LID). When LID is not used and there are multiple Attachments in the request, the Attachments are assigned based on their order of appearance in the request body.
Example Request:
POST https://myHost/polarion/rest/v1/projects/drivepilot/workitems/DP-1285/attachments
The above example also applies to posting or creating a single Attachment. The only difference in the payload is a single entry under the data section of the resource, followed by a single file under the files section of the request body. If the file name is passed as an empty string ("") or null in a POST request, then the passed Input stream file name will be used to set the file name attribute on the attachment.
The alternative way of creating multiple Attachments with a single request is by using the local IDs (LIDs) to assign the content to the corresponding Attachment resources.
Example Request:
POST https://myHost/polarion/rest/v1/projects/drivepilot/workitems/DP-1285/attachments
Insert a Document Attachment to the Document content¶
Attachments that were created for a Document using a POST request do not appear in the Document's content, but they are displayed in the Attachments sidebar. To add them to the Document's content, update the homePageContent field of the Document (with the PATCHDocument endpoint).
To update the Document's content, add an <img src="attachment:attachment_id"/> element to the desired position.
Note
The whole value of homePageContent needs to be sent in the request body, you cannot send the updated or inserted part only.
When setting licenses, the endpoint is POST /users/{userId}/actions/setLicense.
In the following examples, the Polarion license is assigned to the user. The 204 response is returned when successfully assigning a license to the user.
Note
You can assign a license to any user via the REST API as long as they do not already have one. When attempting to set a license to a user that already has one results in a 400 Bad Request response.
To fetch your user avatar use the GET .../user/{ID}/actions/getAvatar endpoint. If you do not have an avatar, the system returns the avatar of the default user.
To create and update your avatar, you can use the POST .../user/{ID}/actions/updateAvatar endpoint. If you send empty data, the avatar is cleared. The maximum allowed size for an avatar file is 50 KB. The file must be in one of the following file formats:
You can also change the workflow status of a Work Item via the REST API by using the workflowAction URL parameter in a PATCH request. The value of the parameter is the ID of the selected action defined in the Workflow configuration.
Request Body (The same as a regular Work Item PATCH):
{"data":{"type":"workitems",
"id":"projectId/workItemId",
"attributes":{"title":"Title after start_progress action"},
"relationships":{"assignee":{"data":[{"id":"admin",
"type":"users"}]}}}}}
All necessary data for the workflow action should be filled in. If some of it is missing, the action generates the following exception:
{"errors":[{"status":"400",
"title":"Bad Request",
"detail":"Start Progress' failed for Work Item 'workItemId': The required field 'assignee' of Work Item 'workItemId' is empty.",
"source":{"parameter":"workflowAction"}}]}
If the workflow change is not allowed based on the current status, the action generates the following exception:
{"errors":[{"status":"400",
"title":"Bad Request",
"detail":"The workflow action 'start_progress' was not found.",
"source":{"parameter":"workflowAction"}}]}
To update Watches for a Work Item, set the list of Watches in the Relationship section of a PATCH request. To add a new user as a Watcher, the entire original list of Watchers must be set with the new added value.
You can use the getWorkflowActionsWork Item action endpoint to get a list of all workflow actions for a Work Item. It returns the list of actions in accordance with the workflow assigned to the Work Item type in the project settings. The data includes a reason for unavailability of unavailable actions.
Example Request:
GET /rest/v1/projects/projectId/workitems/workItemId/actions/getWorkflowActions
Request Body:
{"links":{"self":"http://myhost/polarion/rest/v1/projects/projectId/workitems/workItemId/actions/getWorkflowActions",
"first":"http://myhost/polarion/rest/v1/projects/projectId/workitems/workItemId/actions/getWorkflowActions?page%5Bnumber%5D=1",
"last":"http://myhost/polarion/rest/v1/projects/projectId/workitems/workItemId/actions/getWorkflowActions?page%5Bnumber%5D=1"},
"data":[{"id":"6",
"available":true,
"isSignatureRequired":true,
"isAddingSignature":true,
"nativeActionId":"quickly_accept",
"name":"Quickly Accept",
"requiredFields":["initialEstimate"],
"targetStatus":"accepted",
"requiredRoles":["admin"]},
{"id":"7",
"available":true,
"nativeActionId":"reject",
"name":"Reject",
"requiredFields":["resolution"],
"targetStatus":"rejected"},
{"id":"8",
"nativeActionId":"reviewed",
"name":"Review",
"targetStatus":"reviewed",
"unavailableReason":"Configured workflow condition 'FieldNonEmpty' is not met because Work Item field 'Remaining Estimate' is empty. \nWorkflow transition cannot occur until this condition is satisfied."}]}
GET https://myhost/polarion/rest/v1/projects/projectId/enumerations/~/workitem-type/~
Response Body:
{"links":{"self":"https://myhost/polarion/rest/v1/projects/projectId/enumerations/~/workitem-type/~"},
"data":{"type":"enumerations",
"id":"projectId/~/workitem-type/~",
"attributes":{"options":[{"id":"workpackage",
"name":"Work Package",
"color":"#F1ED92",
"description":"A set of actions that need to be taken to fulfill a goal.",
"iconURL":"/polarion/icons/default/enums/type_userstory.gif"}],
"enumName":"workitem-type"},
"links":{"self":"https://myhost/polarion/rest/v1/projects/UKDrivePilot/enumerations/%7E/workitem-type/%7E"}}}
The REST layer provides endpoints to create, mark, move, unmark, or delete a project.
These actions can take a longer time, because they run as a Polarion Job (Asynchronous Request Reply pattern).
The complete process is executed as a two-step process.
The action is started and you receive the 202 Accepted response if the process starts successfully. The response also sends the jobId of the Polarion Job which is started, along with a link to the job log.
The state and status of the action has to be obtained through the jobs/{jobId} endpoint. If the job finished successfully, the job response contains a project relationship to the changed object.
Example Request (create a project job state and status):
GET /rest/v1/jobs/b512ab11-0af928a3-2b7551ee-8b3ac7d2?fields[jobs]=@all&fields[projects]=@all&include=project
Response Body:
{"links":{"self":"http://localhost:8888/polarion/rest/v1/jobs/b512ab11-0af928a3-2b7551ee-8b3ac7d2?fields%5Bjobs%5D=%40all&fields%5Bprojects%5D=%40all&include=project"},
"data":{"type":"jobs",
"id":"b512ab11-0af928a3-2b7551ee-8b3ac7d2",
"attributes":{"jobId":"b512ab11-0af928a3-2b7551ee-8b3ac7d2",
"name":"Creating project TEST",
"state":"FINISHED",
"status":{"type":"OK"}},
"relationships":{"project":{"data":{"type":"projects",
"id":"TEST"}}},
"links":{"self":"http://localhost:8888/polarion/rest/v1/jobs/b512ab11-0af928a3-2b7551ee-8b3ac7d2",
"log":"http://localhost:8888//polarion/job-report%3FjobId=b512ab11-0af928a3-2b7551ee-8b3ac7d2"}},
"included":[{"type":"projects",
"id":"TEST",
"attributes":{"id":"TEST",
"name":"TEST",
"description":{"type":"text/plain","value":"This model project demonstrates how an actual project might be set up using the 'V-Model Project' template."},
"active":true,
"trackerPrefix":"MYP","icon":"/polarion/icons/default/topicIcons/App_984-demo-drive-pilot.svg","color":"#2A989B"},
"links":{"self":"http://localhost:8888/polarion/rest/v1/projects/MYPROJECT"}}]}
The fact that a Work Item resides in a Document is represented by a relationship module pointing to the corresponding Document resource. If this relationship does not have a value, it is not present in the response when fetching the Work Item resource, which indicates that the Work Item exists outside of any Document.
Work Item action endpoints are provided to move Work Items into, out of, and between Documents.
Specifying the module relationship when creating a Work Item means that the new Work Item is created in the given Document if the authenticated user has the permission to modify that Document (com.polarion.persistence.object.Module.modifyContent).
Example Request:
POST https://myhost/polarion/rest/v1/projects/myProject/workitems
The Work Item is created in the Document's recycle bin by default. To make it actually appear in the Document's content, a separate REST API call is needed to create the corresponding workitem Document Part. See Document Parts for more details.
The module relationship of a Work Item cannot be modified via a PATCH request. The following sections discuss how to move Work Items between Documents.
The move was successful if the 204 - No Content response code is displayed.
Move a Work Item to a Document or between Documents¶
To move a Work Item to a Document (if it was not included in a Document previously), or to move a Work Item between Documents, send the following request and request body:
Example Request:
POST https://myhost/polarion/rest/v1/projects/{projectId}/workitems/{workItemId}/actions/moveToDocument
The previousPart and nextPart parameters are used to specify the position of the moved Work Item in the new Document, either by pointing to the part that it should either follow or precede. Only one of the previousPart/nextPart parameters can be specified, and it must be the ID of an existing part of the target Document. If you do not specify neither previousPart nor nextPart, then the Work Item part is added at the end of the target Document.
The move was successful if the 204 - No Content response code is displayed.
Polarion REST API provides ways to read, create, and manipulate Documents.
Document content can be read, set, or updated using the homePageContent field of the documents resource, or by using the endpoints for working with the structured document_parts.
The renderingLayouts value is not required, but we recommend you set it for new Documents, or add it to the Document resource later using PATCH so that the Work Items in those Documents are rendered as desired.
paragraph is the default value for the layouter field. Other possible values are as follows:
The homePageContent attribute specifies the content of the Document in the Polarion DLE HTML format. If this attribute is missing, REST API automatically creates a single empty paragraph ready to be updated with content via the User Interface or subsequent API calls.
Note
Explicitly sending null or "" as the homePageContent may create a non-editable Document. When creating or updating Documents, there is only limited validation of the provided homePageContent value. If there is some malformed markup or paragraph parts IDs are missing, the change can be saved without errors but it will cause problems when you read the Document by parts. As a solution, either update the Document with a fixed homePageContent value, or alternatively open, edit, and save the Document using the Document-like Editor in the Polarion User Interface.
{"data":{"type":"documents",
"id":"projectId/spaceId/documentId",
"attributes":{"homePageContent":{"type":"text/html",
"value":"<p id=\"polarion_template_0\">This is a text</p><p id=\"polarion_1\"><span style=\"font-size: 10pt;\">Welcome to <span style=\"font-weight: bold;\">Polarion Rest API</span></span></p>"}}}}
Request Body:
204-NoContent
Create and update Headings as part of the Document content¶
When updating a Document'shomePageContent, you can include HTML elements that represent headings and their text. Such HTML parts are automatically converted to Heading Work Items when you save them.
Create and update Headings as part of the Document content¶
A Document Part is the object representation of a top-level HTML node of the Document content. There are different Document Part types that represent different elements inside the Document:
Document element
HTML example
Type
REST ID example
Heading
<h1 id="polarion_wiki macro name=module-workitem;params=id=DPP-100"></h1> OR (for headings bigger than h6) <div class="heading-7" id="polarion_wiki macro name=module-workitem;params=id=DPP-100"></div>
Only one of the previousPart/nextPart fields can be specified. If previousPart/nextPart is not specified, the Work Item is inserted at the end of the Document content. The specified Work Item already has to exist and be present in the Document's recycle bin. See Create a Work Item in a Document for more information..
You can fetch, update (resolve or reopen), and create Document comments via Document Comments endpoints. You can create Replies comments by a POST endpoint specifying the parentComment relationship. Without that relationship a top-level comment is created. A new top-level comment created by the REST API appears as Unreferenced, meaning that it does not appear in the Document's content. To add it to the content, also update the homePageContent field of the Document with the PATCHDocument endpoint.
If the new top-level comment is to be placed in some of the Document's Work Items, the description of the corresponding Work Item resource has to be updated with the same span element instead of Document's content.
To branch a Document, use the Document's resource URL and send a POST request with a special request body like the example below. You can include the revision URL parameter to create a from a specific revision. Without the revision parameter, it will branch from the HEAD. You can also include query in the request body field to specify the Work Items to branch.
To branch several Documents at once, use the /all/documents/actions/branch URL and send a POST request with a special Request Body like in the example below. This action is executed asynchronously, so in the response you receive the ID of a job that was started to perform the task. You can then use another /jobs/{jobId} endpoint to get information about the job's status. If the job finished successfully, the job response contains a documents relationship to all the branched Documents.
To copy a Document, use the Document's resource URL and send a POST request with a special request body like the example below. You can include the revision URL parameter to create a copy from a specific revision. Without the revision parameter, it will copy the HEAD revision.
To merge Work Items between Branched and Master Documents, use the Branch Document's resource URL and send a POST request with a special request body like the example below:
This action is executed asynchronously, so you receive the ID of a job that was started to perform the task in the response. You can then use the /jobs/{jobId} endpoint to get information about the job's status.
If the job finishes successfully, the job response contains a document relationship to the Target Document of the merge.
If the merge finished with some changes in the Target Document, the relationship in the response contains the revision number created by the merge changes.
Enumeration resources are identified by project ID, enumeration context (Document, Plans, Testing or no context), enumeration name, and target type. Enumeration context and enumeration name together (separated by "/", if there is a context) form the enumeration ID known from Java API.
See the table below for examples.
Enumeration ID (Java API)
Enumeration Context
Enumeration Name
Target Type
Note
severity
severity
testcase
A testcase-specific enumeration of severities.
documents/document-status
documents
document-status
A general (not specific to any Document type) configuration of Document statuses.
@document
@document
An object enumeration of Documents.
Note
An empty enumeration context or empty target type is represented in the REST API request URLs by the ~ path parameter. (Because the path parameters cannot be empty.)
In the following sections we describe operations related to enumerations:
CRUD operations are supported for enumerations, however, not all enumerations support all CRUD operations. Some enumerations are not configurable at all - there are constant enumerations (for example approval-status) or object enumerations (for example @document). Such configurations can only be read.
Options that comprise the enumeration are stored in an options attribute (so options themselves are not resources), see the example of a GET response below.
Note
The read enumeration endpoints may return an inherited enumeration, for example an enumeration that does not exist for the exact specified project or target type, but is inherited from the global level or from a general enumeration. Such an inherited configuration cannot be modified (PATCH) or deleted (DELETE). If you want to override the inherited configuration, you need to create (POST) a new configuration for the desired project or target type.
JAVA API fields of enumeration type are available in the REST API as either attributes or relationships (relationships are used for object-based enumerations). For every such field the REST API provides actions to get the current value of the field as a list of options, or to get available options that can be set to the field. In the following sections we will take a look at these actions in more detail.
Note
the enumeration field actions are supported even for object-based enumeration fields of JAVA API that are not yet supported as relationships, so they actually provide the only way to get their value using the REST API.
When a resource has an enumeration attribute (for example severity attribute of the workitems resource), the value of the attribute contains only the ID of the enumeration option (for example critical). To get the corresponding enumeration option with all its details, you can use the getCurrentOptions action available per field.
Note
The response always contains a list of options. For a single valued field this list has one item at most.
For any enumeration field there is a getAvailableOptions action that returns the options fot the corresponding enumeration. This action is provided for a particular resource instance (for example for a particular workitems resource), and also independently of any resource instance of a given target type (for example for workitems of testcase type). The latter case is useful to get the available options when creating a new resource of a given type.
The response format is exactly the same as in the case of getCurrentOptions, so we will not repeat it in the examples below.
Example
GET https://myhost/polarion/rest/v1/projects/myProject/workitems/WI-123/fields/severity/actions/getAvailableOptions
Returns severity options available for the WI-123 Work Item. If the type of the Work Item is testcase, the options are found in the testcase-specific enumeration of severities (or in inherited enumeration, if that specific one is not configured).
Example
GET https://myhost/polarion/rest/v1/projects/myProject/workitems/fields/severity/actions/getAvailableOptions?type=testcase
Returns severity options available for Work Items of the testcase type in the myProject project. The options are found in the testcase-specific enumeration of severities (or in inherited enumeration, if that specific one is not configured).
Available enumeration icons are also resources in the REST API. There are endpoints to get the default icons and custom icons (which can be configured per project or globally).
If a custom plug-in that supplies the object factories implements getEnumOptionPrototypes, then the field that uses the custom object enumeration is displayed as an enum relationship.
Otherwise, it is displayed as a string (the default). The default display is a list of strings if the custom field is a multi-value enum type.
Response Body (GET): For a custom field where custom_testruntemplate_single is supplied but prototype information is not:
If the custom object enumeration factory plug-in does not implement getEnumOptionPrototypes, then the payload must be supplied as a custom attribute for the custom enum option/custom enum options field, and the object is created/updated with the enum option(s).
Request Body (POST): if both a custom field custom_plantemplate_single and prototype information are NOT supplied:
If the custom object enumeration factory plug-in implements the getEnumOptionPrototypes, then the payload must be supplied as a relationship object for the custom enum options field and the object is created/updated with the enum option(s).
Request Body (POST): if a custom field custom_plantemplate_single and prototypes information is not supplied.
Test Management encompasses the artifacts which are instrumental in providing testing-related functionality. Endpoints are provided for the following artifacts:
Test Run
Test Run template
Test Run attachment
Test Run comment
Test Parameter definition
Test Parameter
Test Record
Test Record attachment
Test Step Result
Test Step Result attachment
The endpoint for fetching Test Runs and Test Run templates is the same. The value of the templates query parameter decides whether to fetch Test Run templates or Test Runs.
In Polarion, Test Records are created as a result of the execution of Test Cases. The execution action performs an automatic verification, creates artifacts (for example Defects), and relates them in the background. The execution action is currently not supported on the REST endpoints, so you have to use multiple endpoints to execute and create executed Test Records.
For example, if the Defect that is created when a Test Case fails (since the system is configured to automatically create a Defect if a Test Record fails), the Defect has to be created manually and specified as input relation while creating Test Records.
Test Records are zero indexed on the REST layer.
You have to specify the testCaseRevision parameter if you have to create or update a Test Record with a specific revision of the Test Case.
Test execution using signed context is not yet supported on the REST layer.
{"errors":[{"status":"404",
"title":"Not Found",
"detail":"Test Record 'ProjectID/TestRunIde/TestCaseProject/TestCaseId/0' was not found.",
"source":{"pointer":null,
"parameter":null,
"resource":{"id":"ProjectID/TestRunIde/TestCaseProject/TestCaseId/0",
"type":"testrecords"}}}]}
The REST layer provides endpoints to import Test Results in XUnit and Excel formats. Since the import process can take a long time to complete, the process is run as a Polarion Job (Asynchronous Request Reply pattern).
The complete process is executed as a two-step process:
The import process is started and you receive the 202 Accepted response if the process started successfully. The response also sends the jobId of the Polarion Job which is started, along with a link to the job log.
The state and status of the import process has to be obtained through the jobs/{jobId} endpoint.
{"data":{"type":"jobs",
"id":"8dd9cae6-927aec93-66855dab-098a0106",
"attributes":{"jobId":"8dd9cae6-927aec93-66855dab-098a0106",
"name":"Import of test results",
"state":"RUNNING"},
"links":{"self":"https://myhost/polarion/rest/v1/jobs/8dd9cae6-927aec93-66855dab-098a0106",
"log":"https://myhost/polarion/job-report?jobId=8dd9cae6-927aec93-66855dab-098a0106"}}}
You can export Test Results using the exportTestsToExcel endpoint. You can control the output of the export by supplying the following parameters in the Request Body:
query (a Lucene query to select Test Cases to export)
sortby (the sort criteria for the content of the export)
Polarion Info Pages and LiveReport Pages can be accessed through the Polarion REST API to read and update their properties and default parameter values. (Accessing or modifying the page content is not possible. Working with Page attachments is possible, see Attachments.)
Page parameters show among fields as special attributes with the parameter_ prefix, but only if the particular page parameter has a non-empty default value set and it was explicitly requested to be fetched, or fields[pages]=@all was used.
The following example shows the parameter with severity ID (presented as the parameter_severity attribute) and its current default value. This default value can be modified via the REST API using a PATCH request to the Page resource. It can be used to influence the LiveReport or Info Page content if the parameter value is used by the Page's widgets or scripts.
If you execute the endpoint for a Collection that is already closed, it returns 204 NO CONTENT.
All Document inside the Collection should have a revision other than HEAD otherwise, a 400 BAD REQUEST error is thrown, and the following message appears: Change all HEAD Documents to a baseline or revision before closing the Collection.
Any attempt to change a closed Collection (except reopening) returns 400 with the error message.