Update alert

Namespace: microsoft.graph

Important

APIs under the /beta version in Microsoft Graph are subject to change. Use of these APIs in production applications is not supported. To determine whether an API is available in v1.0, use the Version selector.

Update an editable alert property within any integrated solution to keep alert status and assignments in sync across solutions. This method updates any solution that has a record of the referenced alert ID.

This API is available in the following national cloud deployments.

Global service US Government L4 US Government L5 (DOD) China operated by 21Vianet

Permissions

Choose the permission or permissions marked as least privileged for this API. Use a higher privileged permission or permissions only if your app requires it. For details about delegated and application permissions, see Permission types. To learn more about these permissions, see the permissions reference.

Permission type Least privileged permissions Higher privileged permissions
Delegated (work or school account) SecurityEvents.ReadWrite.All Not available.
Delegated (personal Microsoft account) Not supported. Not supported.
Application SecurityEvents.ReadWrite.All Not available.

HTTP request

Note: You must include the alert ID as a parameter and vendorInformation containing the provider and vendor with this method.

PATCH /security/alerts/{alert_id}

Request headers

Name Description
Authorization Bearer {code}. Required.
Prefer return=representation. Optional.

Request body

In the request body, supply a JSON representation of the values for relevant fields that should be updated. The body must contain the vendorInformation property with valid provider and vendor fields. The following table lists the fields that can be updated for an alert. The values for existing properties that are not included in the request body will not change. For best performance, don't include existing values that haven't changed.

Property Type Description
assignedTo String Name of the analyst the alert is assigned to for triage, investigation, or remediation.
closedDateTime DateTimeOffset Time at which the alert was closed. The Timestamp type represents date and time information using ISO 8601 format and is always in UTC time. For example, midnight UTC on Jan 1, 2014 is 2014-01-01T00:00:00Z.
comments String collection Analyst comments on the alert (for customer alert management). This method can update the comments field with the following values only: Closed in IPC, Closed in MCAS.
feedback alertFeedback enum Analyst feedback on the alert. Possible values are: unknown, truePositive, falsePositive, benignPositive.
status alertStatus enum Alert life cycle status (stage). Possible values are: unknown, newAlert, inProgress, resolved.
tags String collection User-definable labels that can be applied to an alert and can serve as filter conditions (for example, "HVA", "SAW").
vendorInformation securityVendorInformation Complex type that contains details about the security product/service vendor, provider, and subprovider (for example, vendor=Microsoft; provider=Windows Defender ATP; subProvider=AppLocker). Provider and vendor fields are required.

Response

If successful, this method returns a 204 No Content response code.

If the optional request header is used, the method returns a 200 OK response code and an updated alert object in the response body.

Examples

Example 1: Request without Prefer header

Request

The following example shows a request without the Prefer header.

PATCH https://graph.microsoft.com/beta/security/alerts/{alert_id}
Content-type: application/json

{
  "assignedTo": "String",
  "closedDateTime": "String (timestamp)",
  "comments": ["String"],
  "feedback": "@odata.type: microsoft.graph.alertFeedback",
  "status": "@odata.type: microsoft.graph.alertStatus",
  "tags": ["String"],
  "vendorInformation":
    {
      "provider": "String",
      "vendor": "String"
    }
}

Response

The following is an example of a successful response.

HTTP/1.1 204 No Content

Example 2: Request with Prefer header

Request

The following example shows a request that includes the Prefer request header.

PATCH https://graph.microsoft.com/beta/security/alerts/{alert_id}
Content-type: application/json
Prefer: return=representation

{
  "assignedTo": "String",
  "closedDateTime": "String (timestamp)",
  "comments": ["String"],
  "feedback": "@odata.type: microsoft.graph.alertFeedback",
  "status": "@odata.type: microsoft.graph.alertStatus",
  "tags": ["String"],
  "vendorInformation":
    {
      "provider": "String",
      "vendor": "String"
    }
}

Response

The following is an example of the response when the optional Prefer: return=representation request header is used.

Note: The response object shown here might be shortened for readability.

HTTP/1.1 200 OK
Content-type: application/json

{
  "activityGroupName": "activityGroupName-value",
  "assignedTo": "assignedTo-value",
  "azureSubscriptionId": "azureSubscriptionId-value",
  "azureTenantId": "azureTenantId-value",
  "category": "category-value",
  "closedDateTime": "datetime-value"
}