Send Sentinel alerts to a third-party REST API

Microsoft Sentinel has no webhook setting of its own. It sends an alert to an external API by running a playbook, which is an Azure Logic App, and the playbook makes the HTTP request. This guide sets that up in a test workspace, then shows how each part maps to the simulator.

The simulator's Sentinel mode reproduces step 3: the request the playbook's HTTP action sends. Use the simulator for day-to-day testing and a real workspace to confirm the result end to end.

What you need

• An Azure subscription with a Log Analytics workspace that has Microsoft Sentinel enabled.
• The Microsoft Sentinel Contributor and Logic App Contributor roles on the resource group.
• The receiving API's URL and credential. For an Odin integration these are the integration's webhook_url (https://<odin-host>/api/alerts/<integrationId>) and its API key, sent as the X-API-Key header.
• A URL that Azure can reach. A Logic App cannot call localhost; use a deployed environment or a tunnel.

1. Create the playbook

1. In the Azure portal, open Microsoft Sentinel and select your workspace.
2. Go to Configuration > Automation, then select Create > Playbook with alert trigger.
3. Choose the subscription, resource group and a name such as Send-Alert-To-Webhook, then select Next through to Create and continue to designer.

Choose Playbook with incident trigger instead if the receiving API expects incidents. The request body is different; see Request body shapes.

2. Add the HTTP action

1. In the Logic App designer, select + under the trigger and add the built-in HTTP action.
2. Set Method to POST and URI to the receiving API's URL.
3. Add the headers:

   Header	Value
   Content-Type	application/json
   X-API-Key	The API key. Use the header name the receiving API expects.

4. Set Body using one of the expressions in step 3.
5. Open the action's Settings and turn on Secure inputs, so the API key does not appear in the run history.
6. Select Save.

For anything beyond a test workspace, keep the key in Azure Key Vault and read it with the Key Vault Get secret action instead of typing it into the header.

3. Choose the request body

The alert trigger hands the playbook one SecurityAlert record. In that record ExtendedProperties and Entities are JSON strings, not objects. Decide which form the receiving API reads.

Alert, parsed

Odin reads the employee's email from a nested path such as ExtendedProperties,Compromised Entity, so those two fields must be objects. Switch the Body field to the expression editor and enter:

setProperty(
  setProperty(triggerBody(), 'ExtendedProperties', json(triggerBody()?['ExtendedProperties'])),
  'Entities', json(triggerBody()?['Entities'])
)

Simulator setting: Request body > Alert, parsed.

Alert, raw trigger body

Forward the trigger output unchanged. Enter this as the Body expression:

triggerBody()

Simulator setting: Request body > Alert, raw trigger body. Use it to check how the receiving API handles a playbook that skipped the parsing step.

Incident trigger body

With the incident trigger, triggerBody() is an envelope. The incident is at object.properties, its alerts at object.properties.alerts and the people and hosts involved at object.properties.relatedEntities.

Simulator setting: Request body > Incident trigger body.

Field names can differ between connector versions. Before relying on a payload, open one run in the Logic App's Run history and compare the trigger output with the simulator's preview.

4. Let Sentinel run the playbook

1. In Sentinel, go to Configuration > Settings > Settings > Playbook permissions and select Configure permissions.
2. Select the resource group that holds the playbook, then select Apply.

Without this, the playbook does not appear in the list when you create the automation rule.

5. Create a rule that raises test alerts

A scheduled analytics rule with a fixed query raises the same alert on every run, which makes a predictable test source.

1. Go to Configuration > Analytics and select Create > Scheduled query rule.
2. Name the rule. The name becomes the alert's DisplayName. Set the severity.
3. Enter a query that always returns one row:

   print UserPrincipalName = "ada.lovelace@example.com",
         PhishingUrl = "https://login-microsoftonline.acme-secure-portal.com/common/oauth2",
         ClientIP = "5.107.42.118"

4. Under Entity mapping, map Account > FullName to UserPrincipalName and IP > Address to ClientIP.
5. Under Custom details, add any fields the receiving API needs. They arrive inside ExtendedProperties.
6. Set Run query every to 5 minutes and Lookup data from the last to 5 minutes. Leave the threshold at "greater than 0".
7. On the Automated response tab, select Add new, set the trigger to When alert is created, add the action Run playbook and choose your playbook.
8. Select Review + create.

The first alert arrives within a few minutes and repeats on every run. Disable the rule when you finish, or it keeps sending.

6. Check the delivery

• Open the playbook's Logic App and select Run history. Each run shows the request and the response status.
• Select Resubmit on a run to send the same alert again without waiting for the rule.
• To run the playbook by hand, open an incident, select an alert, then Run playbook.

The HTTP action retries on its own. By default it retries up to four times, with growing delays, when the API answers 408, 429 or any 5xx, or when the connection fails. A receiving API can therefore see the same SystemAlertId more than once.

How the simulator maps to Sentinel

The simulator also sends the headers a Logic App adds by itself, including a User-Agent that starts with azure-logic-apps/1.0 and the x-ms-workflow-* headers. It does not retry.

Azure Monitor mode

The other mode reproduces an Azure Monitor action group with a webhook action and Enable the common alert schema turned on. To set up the real thing, go to Monitor > Alerts > Action groups > Create, add an action of type Webhook, enter the URL and enable the common alert schema, then attach the action group to an alert rule.

A plain action group webhook cannot send custom headers; the credential has to go in the URL, or the alert has to pass through a Logic App. The simulator lets you add headers in this mode so the same receiving endpoint can be tested with both payload types.