Audit log records are detailed information about actions and events, which can be provided by any service. For some pre-defined events services always create audit records and the Audit Service always saves them. Audit records have a lifespan of 30 days, after which they will be discarded. **Base path change and deprecation notice** The base path for the Audit APIs is changing (from `/api/audit-service` to `/api/audit`). The `/api/audit-service/` base path will continue to function until `Mon, 31 Mar 2025 23:59:59 GMT`. Additionally, several endpoints are being deprecated. Endpoints that are being deprecated include additional properties in response headers: ``` "Deprecation": "Tue, 31 Dec 2024 23:59:59 GMT", "Link": "New version of API link; rel=\"alternate\"", "Sunset": "Mon, 31 Mar 2025 23:59:59 GMT" ``` * `Deprecation`: The date and time when a resource will be deprecated. After this date, the resource may be removed from future versions of the API. * `Link`: A link to a supported endpoint that replicates the functionality of a deprecated one. * `Sunset`: The date and time when a resource will be removed, and no longer be available. * `Note`: Media type names used in Polaris APIs were renamed and no longer include “synopsys”. Although media types that include “synopsys” were removed from the API specifications, existing endpoints will continue to support them until September 1, 2025. Please update your scripts to use the new media types.

The Bug Tracking Integration API is an integration used to track Polaris issues in Jira. OAuth authentication is used to communicate between this service and the Jira instance. These APIs are only accessible to organization administrators. `Note`: Media type names used in Polaris APIs were renamed and no longer include “synopsys”. Although media types that include “synopsys” were removed from the API specifications, existing endpoints will continue to support them until September 1, 2025. Please update your scripts to use the new media types.

This service provides access to query the issue management services for lists and counts of issue families, managing issue triage as applied to issue families, and unifying issue categorization information. The issue query engine accepts queries written in the [rsql format](https://github.com/jirutka/rsql-parser), which is expressive yet generally easy to write by hand, and has implementations on several different platforms to aid in building queries. A simple filter for an issue family by issue's source language may look like this: `issueProperties:language=in=('C','Java')` Since rsql reserves some characters in the key name, these can be escaped using URL encoding: `type:in-taxon:PCI DSS 2018=='6.5.6 High risk vulnerabilities'` The following keys can be used when querying _issues_: | Key | Filtering | Grouping  | Sorting  | Description  | RSQL Example | | ----------------------------------------------------- | -------------------------------------------- | --------- | ------- | ----------- | ------------ | | `issue:id` | All standard operators and `=null=` operator | ✔ | ✔ | The internal identifier of the issue | `issue:id=='12345'` | `issue:family-id` | All standard operators and `=null=` operator | ✔ | ✔ | The issue family identifier of the issue | `issue:family-id=='67890'` | `issue:`(attribute key) | All standard operators and `=null=` operator | ✔ | ✔ | A named attribute of the issue | `issue:language=in=('C','Java')` The following keys can be used when querying _issue families_: | Key | Filtering | Grouping  | Sorting  | Description  | RSQL Example | | ---------------------------------- | -------------------------------------------- | --------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | `issue:family-id` | All standard operators and `=null=` operator | ✔ | ✔ | The identifier of the issue family | `issue:family-id=='67890'` | `context:portfolio-sub-item-id` | All standard operators and `=null=` operator | ✔ | ✔ | The portfolio subitem ID of the issue family | `context:portfolio-sub-item-id=='port-sub-item-id-123'` | `context:tool-type` | All standard operators and `=null=` operator | ✔ | ✔ | Tool type of the issue family | `context:tool-type=='sast'` | `context:tool-id` | All standard operators and `=null=` operator | ✔ | ✔ | The tool ID of the issue family | `context:tool-id=in=('coverity')` | `issueProperties:`(property key) | All standard operators and `=null=` operator | ✔ | ✔ | A named issue property of the issue family | `issueProperties:severity=in=('high','critical')` | `triageProperties:`(property key) | All standard operators and `=null=` operator | ✔ | ✔ | A named triage property of the issue family | `triageProperties:dismissal-reason=in=('unset','false-positive')` | `issueType:id` | All standard operators and `=null=` operator | ✔ | ✔ | The internal identifier of the issue type | `issueType:id=='5c92259d-528f-4ed6-8fd4-c3c787c42508'` | `issueType:name` | All standard operators and `=null=` operator | ✔ | ✔ | The internal issue type name | `issueType:name=='FB.URF_UNREAD_FIELD'` | `issueType:localized-name` | All standard operators and `=null=` operator | ✔ | ✔ | The localized issue type name | `issueType:localized-name=='AT: Possible atomicity violation'` | `issueType:in-taxon` | All standard operators | ✘ | ✔ | The internal identifier of the taxon | `issueType:in-taxon=='ty-1'`, `issueType:in-taxon=in=('tn-1','tn-2')` | `issueType:children-of-taxon` | ✘ | ✔ | ✘ | The internal identifier of the taxon | `issueType:children-of-taxon:ty-1`, `issueType:children-of-taxon:hty-1` | `derived:fix-by-status` | `==` and `=in=` operators | ✘ | ✘ | One of four keywords: `overdue`, `due-soon`, `on-track`, `not-set`^[3] | `derived:fix-by-status=='overdue'`, `derived:fix-by-status=in=('due-soon','on-track')` | `special:delta` | `==` and `=in=` operators | ✘ | ✘ | One of three keywords: `new`, `common`, `resolved`^[1] | `special:delta=='resolved'`, `special:delta=in=('new','common')` | `special:absent-in-branch` | `==` operator | ✘ | ✘ | Request issue families found in the branch of the `branchId` query param but absent in that of the filter's branch ID^[2] | `special:absent-in-branch=='branch-uuid'` | `special:present-in-branch` | `==` operator | ✘ | ✘ | Request issue families found in the branch of the filter's branch ID but absent in that of the `branchId` query param^[2] | `special:present-in-branch=='branch-uuid'` Notes: 1. A few considerations apply to `special:delta` filter: * It is a comparison filter for tests, and it can only compare two tests - the current one as defined by the `testId` parameter, and the immediately preceding test. * When the `testId` parameter is not specified, the `latest` test is used instead - this special keyword will map to the last test of each tool in the current context. * **Limitation**: If the `latest` keyword maps to multiple tests, it cannot be used with this filter - instead use a specific UUID for the `testId` parameter. * Each keyword has a special meaning: * `new` is for issue families present only in the current test, but not in the preceding test. * `resolved` is for issue families present only in the preceding test, but not in the current test. * `common` is for issue families present in both the current test as well as the preceding test. 2. A few considerations apply to `special:absent-in-branch` and `special:present-in-branch` filters: * The two filters must not both be present in the request. * When one of them is present: * The query parameter `portfolioSubItemId` or `portfolioItemId` should be provided. * The query parameter `branchId` can be provided. It must satisfy the below requirements: * The branches specified by `branchId` and the `special` filter must not be the same. * The branches specified by `branchId` and the `special` filter should not belong to different projects as it is not supported. * If the query parameter `branchId` is not provided: * If `portfolioSubItemId` is provided, the corresponding project's default branch will be used instead. * If `portfolioItemId` is provided, the corresponding application must have only one default branch which will be used instead. * The default branch will need to satisfy the same requirements above for `branchId`. 3. There are four possible values for `derived:fix-by-status`: * `overdue` means that the Fix By date has passed. * `due-soon` means that the Fix By date is within the next 7 days. * `on-track` means that the Fix By date is more than 7 days away. * `not-set` means the the Fix By date has not been set. * **Note:** these states are precise to the second - so a Fix By date in 7 days and 1 minute is `on-track` rather than `due-soon` - similarly, a Fix By date 1 minute ago is `overdue` rather than `due-soon`. ## Media Type Changes Media type names used in Polaris APIs were renamed and no longer include “synopsys”. Although media types that include “synopsys” were removed from the API specifications, existing endpoints will continue to support them until September 1, 2025. Please update your scripts to use the new media types. **Base path change and deprecation notice** The base path for the Findings service is changing (from `/api/specialization-layer-service` to `/api/findings`). The `/api/specialization-layer-service/` base path will continue to function until `2025-09-30T23:59:59.999Z`. Additionally, several endpoints are being deprecated. Endpoints that are being deprecated include additional properties in response headers: ``` "Deprecation": "2025-06-30T23:59:59.999Z", "Link": "New version of API link; rel=\"alternate\"", "Sunset": "2025-09-30T23:59:59.999Z" ``` * `Deprecation`: The date and time when a resource will be deprecated. After this date, the resource may be removed from future versions of the API. * `Link`: A link to a supported endpoint that replicates the functionality of a deprecated one, if one exists. * `Sunset`: The date and time when a resource will be removed, and no longer be available.

The Identity and Access Management Service provides authentication and authorization for all public APIs of the Polaris Platform. In addition to gate-keeping for other services in the platform, Identity and Access Management service offers endpoints for management of organizations, api-tokens, users, application roles, and organization roles. **Base path change and deprecation notice** The base path for the Identity and Access Management API is changing (from `/api/ciam` to `/api/auth`). The `/api/ciam/` base path will continue to function until `Mon, 31 Mar 2025 23:59:59 GMT`. Additionally, several endpoints are being deprecated. Endpoints that are being deprecated include additional properties in response headers: ``` "Deprecation": "Tue, 31 Dec 2024 23:59:59 GMT", "Link": "New version of API link; rel=\"alternate\"", "Sunset": "Mon, 31 Mar 2025 23:59:59 GMT" ``` * `Deprecation`: The date and time when a resource will be deprecated. After this date, the resource may be removed from future versions of the API. * `Link`: A link to a supported endpoint that replicates the functionality of a deprecated one. * `Sunset`: The date and time when a resource will be removed, and no longer be available. * `Note`: Media type names used in Polaris APIs were renamed and no longer include “synopsys”. Although media types that include “synopsys” were removed from the API specifications, existing endpoints will continue to support them until September 1, 2025. Please update your scripts to use the new media types.

**Note:** Media type names used in Polaris APIs were renamed and no longer include “synopsys”. Although media types that include “synopsys” were removed from the API specifications, existing endpoints will continue to support them until `September 1, 2025`. Please update your scripts to use the new media types. Use the Report Service to create, manage, and download reports. The following reports are supported: * Developer detail SCA * Developer detail Static * Executive summary * Issue overview * Issue summary * Security audit * Software bill of materials (SBOM) * Standard compliance * Standard compliance detail * Test summary **Note:** Find descriptions of different reports in the Polaris user documentation, here: [Create a report](https://polaris.synopsys.com/developer/default/polaris-documentation/t_how-to-create-report). To download a preexisting report: 1. Retrieve a list of reports using <code>GET /reports</code>. 2. Download the report using <code>GET /reports/{reportId}/download</code> (with the completed report's `id`).

Notification APs for Polaris **Base path change and deprecation notice** The base path for the Notification APIs is changing (from `/api/notification-service` to `/api/notification`). The `/api/notification-service/` base path will continue to function until `Mon, 31 Mar 2025 23:59:59 GMT`. Additionally, several endpoints are being deprecated. Endpoints that are being deprecated include additional properties in response headers: ``` "Deprecation": "Tue, 31 Dec 2024 23:59:59 GMT", "Link": "New version of API link; rel=\"alternate\"", "Sunset": "Mon, 31 Mar 2025 23:59:59 GMT" ``` * `Deprecation`: The date and time when a resource will be deprecated. After this date, the resource may be removed from future versions of the API. * `Link`: A link to a supported endpoint that replicates the functionality of a deprecated one. * `Sunset`: The date and time when a resource will be removed, and no longer be available. * `Note`: Media type names used in Polaris APIs were renamed and no longer include “synopsys”. Although media types that include “synopsys” were removed from the API specifications, existing endpoints will continue to support them until September 1, 2025. Please update your scripts to use the new media types.

Use the Policies API to create and manage *issue policies*, *component policies* and *test scheduling* policies. * Issue policies: Use issue policies to automate *actions* when issues with specific properties are detected in a test (including setting fix-by dates, if necessary). * Component policies: Use component policies to automate *actions* when a component with specific properties are detected in a test. * Test frequency policies: Use test scheduling policies to automate tests of SCM-integrated branches on a weekly or daily basis. **Base path change and deprecation notice** The base path for the Policy Management service is changing (from `/api/risk` to `/api/policies`). The `/api/risk/` base path will continue to function until `Sun, 1 Dec 2024 23:59:59 GMT`. Additionally, several endpoints are being deprecated. Endpoints that are being deprecated include additional properties in response headers: ``` "Deprecation": "Fri, 1 Nov 2024 23:59:59 GMT", "Link": "New version of API link; rel=\"alternate\"", "Sunset": "Sun, 1 Dec 2024 23:59:59 GMT" ``` * `Deprecation`: The date and time when a resource will be deprecated. After this date, the resource may be removed from future versions of the API. * `Link`: A link to a supported endpoint that replicates the functionality of a deprecated one. * `Sunset`: The date and time when a resource will be removed, and no longer be available. * `Note`: Media type names used in Polaris APIs were renamed and no longer include “synopsys”. Although media types that include “synopsys” were removed from the API specifications, existing endpoints will continue to support them until September 1, 2025. Please update your scripts to use the new media types.

The Portfolio APIs retrieve and update information about Portfolios, Portfolio items (Applications), Portfolio Subitems (Projects), Branches and Tags. `Note`: Media type names used in Polaris APIs were renamed and no longer include “synopsys”. Although media types that include “synopsys” were removed from the API specifications, existing endpoints will continue to support them until September 1, 2025. Please update your scripts to use the new media types.

Repos Integration retrieves and updates information about projects and repos where you have deployed integrations to scan code. It can test the connection between Polaris and the host of your remote repository. **Media type change notice** Media type names used in Polaris APIs were renamed and no longer include “synopsys”. Although media types that include “synopsys” were removed from the API specifications, existing endpoints will continue to support them until September 1, 2025. Please update your scripts to use the new media types.

Test refers to the act of finding security issues in an application. Several types of tests can be performed on the application as per the available Entitlements (SAST, SCA and DAST are currently supported). The Test Manager is responsible for managing tests. It provides APIs to create, update, and fetch tests, manage artifacts related to tests. **Media type change notice** Media type names used in Polaris APIs were renamed and no longer include “synopsys”. Although media types that include “synopsys” were removed from the API specifications, existing endpoints will continue to support them until September 1, 2025. Please update your scripts to use the new media types.

Handles retrieval of command line tools and tool-related information. You can download the CI Integration tool, and use it when you want to start a scan from the command line. The CI Integrations tool will download other tools for scanning and uploading code when they are needed. <p>To download the CI Integrations tool follow this workflow:<ol><li>Get the tool ID for the latest version of the tool, using <code>GET /tools</code>.</li><li>Use the tool ID to retrieve a signed link from `GET /download-descriptors/{id}`. You can use this link to download the CI Integrations tool.</li></ol></p> **Media type change notice** Media type names used in Polaris APIs were renamed and no longer include “synopsys”. Although media types that include “synopsys” were removed from the API specifications, existing endpoints will continue to support them until September 1, 2025. Please update your scripts to use the new media types.