List incidents
Relative path: /v2/incidents
Returns a list of incidents matching the filter
.
The list is ordered according to order_by
.
Info: This API call does not return deviceUuids
and detectionUuids
. To retrieve these details, execute the GET /v2/incidents/{incidentUuid} API call for a specific incident.
Filtering
Field names for filtering must be specified using the snake case or the lower camel case, for example, display_name or displayName.
Supported fields for filtering are:
•create_time
•update_time
•display_name
•assignee_uuid
•device_uuids
•severity
•status
•tags
Operators for filtering
•==—Equality operator, for example, incident.display_name == "name"
•!=—Inequality operator, for example, incident.assignee_uuid != "uuid"
•<=—Less than or equal to operator, for example, incident.create_time >= timestamp("2025-10-01T12:30:00+00:00")
•>=—Greater than or equal to operator, for example, size(incident.device_uuids) >= 10 or incident.device_uuids.size() >= 10
•in—Filters items with values specified in the list, for example, incident.severity in [INCIDENT_SEVERITY_LEVEL_LOW,INCIDENT_SEVERITY_LEVEL_MEDIUM]
•contains—Filters items where the value contains the specified text, for example, incident.display_name.contains("xyz")
•has—Filters items that have the specified key, for example, has(incident.assignee_uuid)
•&&—"And" operator, mostly used for time filtering, for example, incident.create_time >= timestamp("2025-04-07T00:00:00Z") && incident.create_time <= timestamp("2025-04-18T23:59:59Z")
Status filtering examples
Filter by status using only the in or == operator.
incident.status in [INCIDENT_STATUS_IN_PROGRESS, INCIDENT_STATUS_OPEN] incident.status == INCIDENT_STATUS_IN_PROGRESS |
Severity filtering examples
Filter by severity using only the in or == operator.
incident.severity in [INCIDENT_SEVERITY_LEVEL_MEDIUM, INCIDENT_SEVERITY_LEVEL_HIGH] incident.severity == INCIDENT_SEVERITY_LEVEL_HIGH |
Time filtering examples
Filter by create_time or update_time using the timestamp offset or UTC representation as in the examples below.
incident.create_time >= timestamp("2025-10-01T12:30:00+00:00") incident.create_time <= timestamp("2025-10-01T12:30:00+00:00") - duration('10m') incident.create_time >= timestamp("2025-04-07T00:00:00+00:00") && incident.create_time <= timestamp("2025-04-18T23:59:+00:00") incident.create_time >= timestamp("2025-10-01T12:30:00Z") incident.create_time <= timestamp("2025-10-01T12:30:00Z") - duration('10m') incident.create_time >= timestamp("2025-04-07T00:00:00Z") && incident.create_time <= timestamp("2025-04-18T23:59:59Z") |
UUID filtering examples
Filter by uuid using comparison filters.
!has(incident.assignee_uuid) has(incident.assignee_uuid) incident.assignee_uuid == "uuid" incident.device_uuids.contains("uuid") //an array of device_uuids contains the required uuid |
Display name filtering examples
incident.displayName == "name" incident.displayName.contains("abc") !incident.displayName.contains("xyz") displayName == "name" displayName.contains("abc") !displayName.contains("xyz") |
Ordering
Field names for ordering must be specified using the snake case, for example, display_name.
Supported fields for ordering are:
•display_name
•create_time
•update_time
•severity
•status
•device_uuids.count
•detection_uuids.count
Query parameters
Name |
Type |
Description |
---|---|---|
filter |
string |
A filter string compliant with Filtering. Field names must be expressed in lower_case_with_underscores form or in lowerCamelCase form, for example, display_name or displayName. For time filtering, use the timestamp offset representation. Examples: - incident.create_time >= timestamp("2024-10-01T12:41:39+00:00") - incident.assignee_uuid == "uuid" - incident.displayName.contains("abc") - displayName.contains("abc")
|
orderBy |
string |
It is a comma-separated list of fields. The default sorting order is ascending. To specify the descending order for a field, users must append a " desc" suffix. All actual fields and subfields from the object [Incident] can be used. Subfields are specified with a . character. Field names must be expressed in lower_case_with_underscores form, for example, display_name.
For example, the result will be ordered by the device name given by the user and by the incident severity in the reverse order: display_name, severity desc |
pageSize |
integer |
Limit for pagination purposes. If unspecified or 0, the default value is 50. The maximum value is 1000; values above 1000 will be coerced to 1000.
|
pageToken |
string |
Page token of the current page. If not given or "", the first page is returned.
|
Responses
Display Schema instead of an Example or vice-versa
Code |
Description |
Example |
Schema |
---|---|---|---|
200 |
Successful response. |
{ "incidents": [ { "assigneeUuid": "string", "createTime": "string", "description": "string", "detectionUuids": [ "string" ], "deviceUuids": [ "string" ], "displayName": "string", "metrics": { "deviceCount": 0, "executableCount": 0, "processCount": 0 }, "resolveReason": "INCIDENT_RESOLVE_REASON_UNSPECIFIED", "responseDuration": "string", "severity": "INCIDENT_SEVERITY_LEVEL_UNSPECIFIED", "status": "INCIDENT_STATUS_UNSPECIFIED", "tags": [ "string" ], "triageDuration": "string", "updateTime": "string", "uuid": "string" } ], "nextPageToken": "string" } |
{ "$ref": "v2ListIncidentsResponse", "incidents": [ { "$ref": "v2Incident", "description": { "type": "string", "description": "Arbitrary text describing the incident." }, "assigneeUuid": { "type": "string", "description": "User responsible for investigation and remediation. type: user_management.v1.User" }, "createTime": { "type": "string", "description": "Timestamp for when the incident was created.", "format": "date-time", "readOnly": true }, "detectionUuids": [ { "type": "string" } ], "deviceUuids": [ { "type": "string" } ], "displayName": { "type": "string", "description": "Human-readable name of the incident." }, "metrics": { "$ref": "v2IncidentMetrics", "description": "Metrics related to the incident.", "deviceCount": { "type": "integer", "description": "Count of devices related to the incident.", "format": "int64" }, "executableCount": { "type": "integer", "description": "Count of executables related to the incident.", "format": "int64" }, "processCount": { "type": "integer", "description": "Count of processes related to the incident.", "format": "int64" } }, "resolveReason": { "$ref": "v2IncidentResolveReason", "type": "string", "description": "Possible reasons for resolved incident. INCIDENT_RESOLVE_REASON_UNSPECIFIED: fallback INCIDENT_RESOLVE_REASON_TRUE_POSITIVE: The incident was a true positive, indicating a genuine security threat. INCIDENT_RESOLVE_REASON_FALSE_POSITIVE: The incident was initially thought to be a security threat but later determined to be a false alarm. INCIDENT_RESOLVE_REASON_SUSPICIOUS: The incident is not a confirmed threat (true positive), but investigating it can provide valuable insights into user behavior patterns and help mitigate potential attacks.", "default": "INCIDENT_RESOLVE_REASON_UNSPECIFIED", "enum": [ "INCIDENT_RESOLVE_REASON_UNSPECIFIED", "INCIDENT_RESOLVE_REASON_TRUE_POSITIVE", "INCIDENT_RESOLVE_REASON_FALSE_POSITIVE", "INCIDENT_RESOLVE_REASON_SUSPICIOUS" ] }, "responseDuration": { "type": "string", "description": "How long it took to respond to the incident.", "readOnly": true }, "severity": { "$ref": "v2IncidentSeverityLevel", "type": "string", "description": "Severity levels abstracted to cover all the possible GUIs. Vocabulary is leaving interpretation of severity level completely to API client. Info: This approach is inevitable on SIEM level as there are many contributing sources. Keeping the local names for severity levels never fits all the GUIs. INCIDENT_SEVERITY_LEVEL_UNSPECIFIED: fallback INCIDENT_SEVERITY_LEVEL_LOW: In some GUIs known as Warning INCIDENT_SEVERITY_LEVEL_MEDIUM: In some GUIs known as Error or Threat INCIDENT_SEVERITY_LEVEL_HIGH: In some GUIs known as Critical", "default": "INCIDENT_SEVERITY_LEVEL_UNSPECIFIED", "enum": [ "INCIDENT_SEVERITY_LEVEL_UNSPECIFIED", "INCIDENT_SEVERITY_LEVEL_LOW", "INCIDENT_SEVERITY_LEVEL_MEDIUM", "INCIDENT_SEVERITY_LEVEL_HIGH" ] }, "status": { "$ref": "v2IncidentStatus", "type": "string", "description": "Defines an enumeration for incident status. INCIDENT_STATUS_UNSPECIFIED: fallback INCIDENT_STATUS_OPEN: The incident is OPEN (also known as NEW) and has been reported or detected. INCIDENT_STATUS_IN_PROGRESS: The incident is currently in progress and being actively addressed. INCIDENT_STATUS_CLOSED: The incident has been closed, and the necessary actions have been taken.", "default": "INCIDENT_STATUS_UNSPECIFIED", "enum": [ "INCIDENT_STATUS_UNSPECIFIED", "INCIDENT_STATUS_OPEN", "INCIDENT_STATUS_IN_PROGRESS", "INCIDENT_STATUS_CLOSED" ] }, "tags": [ { "type": "string" } ], "triageDuration": { "type": "string", "description": "How long incident remained in triage status.", "readOnly": true }, "updateTime": { "type": "string", "description": "Represents the timestamp when the resource was most recently updated. Any change to the resource made by users (create/update/delete) must update this value; changes to a resource made internally by the service should refresh this value unless specified otherwise on the entity level. Info: Modeled after Standard fields: Timestamps", "format": "date-time", "readOnly": true }, "uuid": { "type": "string", "description": "Unique identifier of the entity. Must be collision-free - two identifiers created anywhere in the world must not collide within entity parent scope. Unless a member of aggregate, the entity scope is always global. Although most of the times compliant with RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace, do not rely on it being a RFC UUID. Treat it as an opaque identifier. RFC UUID can be recognized by being formatted according to the template xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, as explained on Wikipedia. UUID is used for referencing an entity, even across domains. Example: '123e4567-e89b-12d3-a456-426614174000'" } } ], "nextPageToken": { "type": "string", "description": "Page token of the next page. Empty or '' for the last page. Info: For more information, refer to Paginating Requests in APIs or Design Patterns: Pagination" } } |
202 |
Response took too long; request cached. Response can be retrieved later using the response-id header. |
null |
[] |
400 |
One of the errors: 1. Bad or missing authorization. 2. Validation error. Invalid argument provided. |
null |
[] |
401 |
Token has expired or is invalid. |
null |
[] |
403 |
Access denied. Check permissions. |
null |
[] |
404 |
Requested resource not found. |
null |
[] |
429 |
Rate limit reached. Try again later. |
null |
[] |
500 |
Internal server failure. Try again later. |
null |
[] |
502 |
Internal server failure. Try again later. |
null |
[] |
503 |
Environment under maintenance. Try again later. |
null |
[] |
504 |
Action took too long; timeout reached |
null |
[] |