adding API content

Author: batamig

articles/sentinel/move-to-defender.md

@@ -124,10 +124,33 @@ For more information, see [Automation in the Microsoft Defender portal](/azure/s
 
 The unified experience in the Defender portal introduces notable changes to incidents and alerts from APIs. It supports API calls based on the [Microsoft Graph REST API v1.0](/graph/api/resources/security-api-overview?view=graph-rest-1.0), which can be used for automation related to alerts, incidents, advanced hunting, and more.
 
-The [Microsoft Sentinel API](/rest/api/securityinsights/api-versions) continues to support actions against Microsoft Sentinel resources, like analytics rules, automation rules and more.   For interacting with unified incidents and alerts, we recommend that you use the Microsoft Graph REST API.
+The [Microsoft Sentinel `SecurityInsights` API](/rest/api/securityinsights/api-versions) continues to support actions against Microsoft Sentinel resources, like analytics rules, automation rules and more. For interacting with unified incidents and alerts, we recommend that you use the Microsoft Graph REST API.
 
-If you're using the Microsoft Sentinel `SecurityInsights` API to interact with Microsoft Sentinel incidents, you may need to update your automation conditions and trigger criteria due to changes in the response body. For more information, see [API responses](/azure/sentinel/microsoft-sentinel-defender-portal?branch=pr-en-us-299307#api-responses). <!--fix link-->
+For example, when using an HTTP GET command for a specific unified incident with the Microsoft Graph REST API, the body response has the following differences:
 
+- The `incidentWebUrl` field provides the direct link to the incident, which can be used to synchronize this information with a third-party ticketing system like ServiceNow.
+
+- If the response doesn't contain the `alertProductNames` array, retrieve it by updating the initial HTTP GET command to add `?$expand=alerts` after the GET command. For example: `https://graph.microsoft.com/v1.0/security/incidents/368?$expand=alerts`
+
+If you're using the Microsoft Sentinel `SecurityInsights` API to interact with Microsoft Sentinel incidents, you may need to update your automation conditions and trigger criteria due to changes in the response body.
+
+The following table lists fields that are important in the response snippets, and compares them across the Azure and Defender portals:
+
+|Functionality  | Azure portal  |Defender portal  |
+|---------|---------|---------|
+|The source that triggered the detection and published the alert     |     `alertProductNames`    |   `productName`      |
+|Link to the incident     |    `incidentUrl`, links to the incident in Microsoft Sentinel in the Azure portal     |  `providerIncidentUrl`, links to the incident in the Defender portal       |
+|The name of the alert provider     |   `providerName`      |   `providerName` always shows as `Microsoft XDR`      |
+
+The following table lists all elements that are added or changed in the Microsoft Sentinel `SecurityInsights` API after onboarding your workspace to the Defender portal:
+
+| Field     | Change Description     |
+|----------------------|----------|
+| `detectionSource`    | Added. The detection technology or sensor that identified the notable component or activity. |
+| `productName`        | Added. The name of the product that published this alert.                         |
+| `providerIncidentUrl`| Added. Provides the direct URL to the incident in the unified portal.              |
+| `providerName`       | Updated. The providerName field value has been changed from *"Azure Sentinel"* to *"Microsoft XDR"*. |
+| `serviceSource`      | Added. The service or product that created the alert.                             |
 
 ## Run operations in the Defender portal