Skip to main content

Upcoming API Update: Improved Handling of Cloned Alerts

Updated

To improve data integrity and provide better context within your automated workflows, we are introducing a breaking change to how our API handles cloned alerts.

What is Changing?

In our upcoming release, we are updating the behavior of four specific GET endpoints. Previously, requesting a cloned alert would return the alert data directly. Moving forward, the API will return a 409 Conflict error if the requested alert is a clone.

Also, please note that on the platform, cloned alerts will no longer be displayed on the Investigation page.

This change is designed to reduce noise and help you focus on unique, high-priority incidents.

Definition:

A clone alert is an alert ingested by our system that has the exact same raw data as another alert that we already investigated. 

Technical Details

If you attempt to GET a cloned alert, the API will respond as follows:

  • Status Code: 409 Conflict

  • Error Payload: Includes the reference_alert_id

Impacted Endpoints:

  1. GET /v2/investigations/{alert_id}/results

  2. GET /v2/investigations/{alert_id}/results/{section}

  3. GET /v2/investigations/{alert_id}/html

  4. GET /v2/investigations/{alert_id}/html/{section}

Example Error Response:

{
  "detail": {
    "message": "This alert describes the same incident as ALT-12345",
    "alert": {
      "id": "ALT-12345",
      "profile_id": "PROF-789",
      "external_id": "EXT-001",
      "metadata": {...},
      "title": "Suspicious Login Activity",
      "index": "logs-auth-001",
      "received_at": "2023-10-27T10:00:00Z"
    },
    "status": "CLONE"
  }
}}

Action Required: Updating Your SOAR Playbooks

Because the 409 error payload contains only a summary of the original alert, you will need to update your automation logic to perform a second query to retrieve the full alert details.

  1. Catch the 409 Error: Update your integration logic to listen for the 409 Conflict status code.

  2. Extract the Reference ID: Parse the response body to get the detail.alert.id.

  3. Perform a Follow-up Request: Initiate a new GET request using that id to fetch the complete alert data

  4. Deduplication: Use this logic to link the current workflow to the existing "Reference" incident in your SOAR, avoiding the creation of duplicate tickets.

Release Timeline

  • Production Deployment: 21/01/2026. 

Coming Soon

We will introduce a change where alerts flagged by our system as duplicates benefit from the same investigation as a chosen reference alert. 

Definition: A duplicate alert is an alert ingested by our system that has the exact same security observables as another alert that we already investigated. This is less restrictive than clone alerts.

 
 

Related articles