---
title: "Add Response Actions"
slug: "add-response-actions"
updated: 2026-09-09T16:09:29Z
published: 2026-09-09T16:09:29Z
canonical: "docs.redcanary.com/add-response-actions"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.redcanary.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Add Response Actions

> [!NOTE]
> **Note:** Red Canary is now Zscaler MDR. Please bear with us while we update the naming in our third-party integrations.

Automations aim to enhance efficiency, reduce manual intervention, and ensure timely responses to various events or incidents. Zscaler MDR provides several automations for different tools to improve readiness, ensure reliability and coverage, or to take action.

Refer to the below examples:

## Add a Microsoft Sentinel Response Action

Microsoft Sentinel is Microsoft’s cloud-native SIEM and SOAR platform. You can configure Zscaler MDR Automate to send published threats to Microsoft Sentinel so Sentinel can create alerts and incidents from Zscaler MDR detection data.

This setup uses the Red Canary Microsoft Sentinel connector based on Microsoft’s Codeless Connector Framework (CCF) and the Azure Monitor Logs Ingestion API.

Before you begin, you need:

- Access to Microsoft Sentinel
- Permission to install Content Hub solutions
- Permission to deploy connector resources in the Sentinel workspace
- Permission to create Microsoft Entra app registrations and assign the required Azure role, or help from an Azure administrator who has those permissions
- Access to Zscaler MDR Automate

> [!NOTE]
> Note
> 
> If you already use the older Red Canary Microsoft Sentinel action, you may see an action named **Send Threat to Sentinel (Legacy)**. That legacy action uses a Workspace ID and Primary Shared Key and will be deprecated in September of 2026.
> 
> 
> 
> For new Microsoft Sentinel setups, use the new action **Send Threat to Sentinel** without the **Legacy** label. This action uses the connector values generated by Microsoft Sentinel and does not use a Workspace ID or Primary Shared Key.

### Install the Zscaler MDR Solution in Microsoft Sentinel

1. Sign in to the Azure portal.
2. Open Microsoft Sentinel.
3. Select the Sentinel workspace where you want Zscaler MDR detections to appear.
4. Go to **Content management > Content hub**.
5. Search for “Red Canary.”
6. Select the Red Canary solution.
7. Select **Install**.
8. After installation completes, refresh the page if the connector or analytic rule does not appear immediately.

### Confirm the Installed Content

After installing the solution, confirm that Microsoft Sentinel created the expected content.

1. Go to **Configuration > Data connectors**.
2. Confirm that Red Canary Threat Detection (via Codeless Connector Framework) is available.
3. Go to **Configuration > Analytics**.
4. Confirm that the Red Canary Threat Detection rule template is available.

The analytic rule may be disabled when it is first installed. This is expected. You can enable it after the connector resources and Red Canary action are configured.

### Deploy the Red Canary Connector Resources

1. In Microsoft Sentinel, go to **Configuration > Data connectors**.
2. Select **Red Canary Threat Detection (via Codeless Connector Framework)**.
3. Select **Open connector page**.
4. Select **Deploy Red Canary connector resources**.
5. Wait for deployment to complete.

The connector deployment creates the resources Zscaler MDR needs to send detections through the Logs Ingestion API:

- `RedCanaryDetections_CL` custom table
- Data Collection Endpoint (DCE)
- Data Collection Rule (DCR)
- Microsoft Entra application
- Application secret

> [!CAUTION]
> Warning
> 
> The application secret is sensitive and should be handled like a password.
- Role assignment that allows the application to send records to the DCR
- Push data connector instance

### Copy the Connector Values

After the connector resources are deployed, stay on the Red Canary connector page in Microsoft Sentinel. The generated values appear on that connector page below the Deploy Red Canary connector resources button.

Copy these five values from the Microsoft Sentinel connector page into Red Canary:

- Tenant ID (Directory ID)
- Entra App Registration Application ID
- Entra App Registration Secret
- Data Collection Endpoint URI
- Data Collection Rule Immutable ID

Keep the five copied values available while you configure the Red Canary action. The Entra App Registration Secret is sensitive and should be handled like a password.

> [!NOTE]
> Note
> 
> The connector page may also show the detections stream name `Custom-RedCanaryDetections`. You do not need to paste this into Red Canary— the Red Canary Microsoft Sentinel action uses `Custom-RedCanaryDetections` automatically.

### Create a Zscaler MDR Playbook Action

1. In the Zscaler MDR portal, go to **Automate**.
2. Select **Playbooks**.
3. Create a new playbook, or open an existing playbook.
4. Select **Add Action**.
5. Select **Send Threat to Sentinel**.
6. Enter the five connector values copied from the Microsoft Sentinel connector page:

> [!CAUTION]
> Warning
> 
> **Do not** enter a Workspace ID or Primary Shared Key for the new action. Those values only apply to the legacy Microsoft Sentinel action.
> 
> **Do not** enter a stream name. Zscaler MDR sends to `Custom-RedCanaryDetections`.
  - Tenant ID (Directory ID)
  - Application ID (Entra App Registration Application ID)
  - Application Secret (Entra App Registration Secret)
  - Data Collection Endpoint URI
  - Data Collection Rule Immutable ID
7. Save the action.
8. Save the playbook.

### Connect the playbook to a trigger

1. In the Zscaler MDR portal, go to **Automate**.
2. Select **Triggers**.
3. Create a new trigger, or open an existing trigger.
4. Use the **When a Threat is published** trigger condition.
5. Add the playbook that contains the **Send Threat to Sentinel** action.
6. Save the trigger.
7. Enable the Sentinel analytic rule.
8. In Microsoft Sentinel, go to **Configuration > Analytics**.
9. Find the Red Canary Threat Detection rule template.
10. Create or enable the scheduled analytic rule. The rule creates Microsoft Sentinel alerts and incidents from records in `RedCanaryDetections_CL`.

### Validate the setup

To test the setup, manually run the Red Canary playbook against a threat or wait for a published threat that matches the trigger.

> [!NOTE]
> Note
> 
> The analytic rule runs on a schedule, so alerts and incidents may take several minutes to appear after the raw record is ingested. If incidents are not visible in the Sentinel UI, clear any active filters and search for Red Canary has published Detection.

To validate raw ingestion in Microsoft Sentinel:

```plaintext
RedCanaryDetections_CL

| sort by TimeGenerated desc

| project TimeGenerated, detection_id_s, detection_headline_s, detection_severity_s, host_name_s
```

To check a specific Red Canary detection ID:

```plaintext
RedCanaryDetections_CL

| where detection_id_s == "<red-canary-detection-id>"

| summarize Rows=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by detection_id_s
```

To validate alerts:

```plaintext
SecurityAlert

| where AlertName has "Red Canary has published Detection"

| sort by TimeGenerated desc
```

To validate incidents:

```plaintext
SecurityIncident

| where Title has "Red Canary has published Detection"

| sort by TimeGenerated desc
```

## Add a Microsoft Teams Response Action

Zscaler MDR’s Microsoft Teams integration allows Teams messages to be created as part of an automation playbook.

### Configure Teams to Accept an Incoming Webhook or Workflow URL

1. Add a [custom incoming webhook](https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/connectors#setting-up-a-custom-incoming-webhook) or [Workflow URL](https://support.microsoft.com/en-us/office/create-incoming-webhooks-with-workflows-for-microsoft-teams-8ae491c7-0394-4861-ba59-055e33f75498) within Microsoft Teams.
2. Copy the resulting webhook URL or Workflow URL.

### Add a Teams Notification to an Automation playbook

1. Within any playbook click **Add Action**.
2. Click **Microsoft Teams** and then click **Send Microsoft Teams Message**.
3. Click **Add to Playbook**.
4. Enter the webhook URL or Workflow URL from above in **Microsoft Teams Webhook URL / Workflow URL**.
5. Specify the **Title** and **Text** you want to appear for each message.

> **Note**
> 
> HTML tags are not supported in Microsoft Teams Adaptive Cards. While Markdown is supported, it only works in a limited capacity within the `TextBlock` field.
> 
> 
> 
> What works:
> 
> - Using `**bold text**` or `__bold text__` for bold formatting
> - Using `_italic_` or `*italic*` text for italic formatting
> - Using multiple `TextBlock` elements for line breaks or spacing
> - Using `TextBlock` properties like `weight`, `size`, and `color` for additional formatting
> 
> What doesn’t work:
> 
> - Using HTML tags like `&lt;br&gt;`, `&lt;b&gt;`, and `&lt;i&gt;`
> - Using escape sequences like `\n` and`\r` for line breaks
> - Using Markdown horizontal rules like `---` and `***`
> - Using Native horizontal rules (no built-in separator element)
6. Optionally, click **Add a Potential Action** and specify an action name and URL that should be triggered when the action is selected ([learn more about actions in Microsoft Teams messages](https://developer.microsoft.com/en-us/microsoft-teams/blogs/take-actions-right-from-messages-in-microsoft-teams/)).
7. Click **Save**.

## Add a Opsgenie Response Action

Opsgenie integration allows Zscaler MDR to create Opsgenie Alerts as part of an automation playbook.

1. In any playbook, click **Add Action**.
2. Click **Create OpsGenie Alert** and then click **Add to Playbook**.
3. Specify the Opsgenie API key (This information can be found on the Opsgenie “integrations” page under the APIs tab)
4. Specify the Alert Message (NOTE: this field has a limit of 130 characters. Additional characters will be truncated.)
5. Specify the Alert Description
6. Select the desired Alert Priority. The default value is *P3.*

### Close Opsgenie Alerts

Opsgenie alerts can also be closed by Zscaler MDR automation.

For example, a playbook may use **Create Opsgenie Alert** when a detection is published, and may then use **Close Opsgenie Alert** when a detection is acknowledged*.* This works because the same detection triggers both the incident creation and resolution actions.

1. In any playbook, click **Add Action**.
2. Click **Close OpsGenie Alert** and then click **Add to Playbook**.
3. Specify the Opsgenie API key (This information can be found on the Opsgenie “integrations” page under the APIs tab)
4. Specify the Alert Note

## Add a PagerDuty Response Action

PagerDuty integration allows Zscaler MDR to trigger PagerDuty incidents as part of an automation playbook.

1. In any playbook, click **Add Action**.
2. Click **PagerDuty**, **Create PagerDuty Incident** and then click **Add to Playbook**.
3. Specify the incident message you want to appear in each PagerDuty incident.
4. Click **Save & Connect with PagerDuty**.
5. You will be redirected to the PagerDuty site and asked to authorize Zscaler MDR. Following that, you will be returned to Zscaler MDR.

When the playbook is triggered, a PagerDuty incident will appear.

![mceclip0.png](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/5ubgixxa0saec3ymuqtqmceclip0.png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A14Z&se=2026-11-09T12%3A54%3A14Z&sr=c&sp=r&sig=buaJkfeobNTTTxl41MczqpqCjHMoKh12TaemI9Zzpr4%3D)

### What details are included in the PagerDuty incident?

Custom details may be specified for each incident using the PagerDuty API. Zscaler MDR adds several fields when a PagerDuty incident is triggered.

For audit logs:

- **actor** is set to the name and email of the user triggering the audit log.
- **timestamp** is set to the time the audit log was created.
- **action_name** is set to the name of the action that occurred.

For activity monitors:

- **activity_monitor** is set to the activity monitor’s name.
- **num_matches_found** is set to the number of matches that were found recently, or were found in this notification.

For threats:

- **severity** is set to the detection’s severity.
- **classification** is set to the detection’s root classification.
- **subclassifications** is set to a comma-separated list of the detection’s subclassifications.
- A PagerDuty link is included that links to the confirmed threat in Zscaler MDR.

### Resolve PagerDuty Incidents

Each Zscaler MDR incident has an incident key associated with the underlying resource that triggered the automation, such as an audit log, detection, or endpoint. These incidents can also be resolved by Zscaler MDR automation.

For example, a playbook may use **Create PagerDuty Incident** when a detection is published, and may then use **Resolve PagerDuty Incident** when a detection is acknowledged*.* This works because the same detection triggers both the incident creation and resolution actions.

## Add a Phone Call Response Action

Add a phone call to your automation playbook that will call specified phone numbers either when the playbook runs or when all actions in a playbook have been successfully completed. These phone numbers are called in sequential order until a recipient acknowledges the call by pressing 1. At this time, there isn't a limit on the number of phone numbers that can be added.

1. From the navigation menu, click **Automations**.
2. Click **Playbooks**, and then click into a playbook.
3. Click one of the two **Add Action** buttons depending on when the phone number should be triggered.

For example, click **Add Action** under **When this playbook is run**, the following actions will be performed in no particular order to trigger the phone calls whenever the playbook is run.
4. From Phone Call, click **Call Phone Numbers**, and then click **Add to Playbook**.
5. Enter one or more comma-separated phone numbers that should receive the phone call. Add phone numbers using the 164 format, including + and the country code. For example, +16175551212.

> [!NOTE]
> Note
> 
> These can be determined dynamically using variables, such as using `$Detection.marked_acknowledged_by_user.phone` to call the user who acknowledged a threat.
6. Enter the Message for the recipient.
7. Specify the number of seconds to wait before calling the next number.
8. Optionally, select **Require approval**.
9. Click **Save**.

Use an automation playbook to set up a phone integration that will call specified phone numbers based on trigger criteria. The automation will call the phone numbers listed in the playbook by order until the recipient acknowledges the alert by pressing 1 or 10 retries are exhausted.

For example, if three phone numbers are listed, they will be called in the following order:

1. Call phone number 1.
2. If unanswered or the recipient presses 2 to ignore the message, call phone number 2.
3. If unanswered or the recipient presses 2 to ignore the message, call phone number 3.
4. If unanswered or the recipient presses 2 to ignore the message, call phone number 1 again.
5. Repeat this up to 10 times.

SMS integration allows Zscaler MDR to send SMS messages as part of an automation playbook.

## Add a Send Email Response Action

### Send Email Setup

Zscaler MDR allows for emails to be sent as part of any automation playbook. To add the action, follow the steps below:

1. Within any playbook, click **Add Action** then scroll down until you see **Email**.
2. Click **Add** next to the **Send Email** action, then fill in the email action’s fields:
  1. Use the **From** field to set a custom sender address
  2. Use the **To** field to define the email recipient addresses
  3. Use the **Reply To** field to define addresses for responses
  4. Use the **Subject** field to define a subject for the email
  5. Select an email **Template** from the available options
  6. Create a email **Message** based on the template selected
3. If desired, configure the Send Email action’s optional settings:
  1. Select **SMTP** to configure a custom SMTP relay for sending emails
  2. Select **Require Approval** to approve each email before sending
4. Click **Save** to finalize and add the email action to your playbook

> [!NOTE]
> **Note**
> 
> The Send Email action allows you to use object attributes to dynamically customize email content. For example, using `$Detection.marked_acknowledged_by_user.email` will send an email to the user who acknowledged a detection. Learn more at [Understand Playbook Features and Attributes](/doc/docs/playbook-features-and-attributes).

### SMTP Configuration

The Send via SMTP option allows emails to be sent using your own SMTP server to increase deliverability. To use a custom SMTP server in a Send Email action, follow the steps below:

1. Below the message field, check the box labeled **Send via custom SMTP relay/server (advanced)**.
2. Enter the hostname or IP address of your SMTP server in the **SMTP Host** field.
3. Input the **SMTP Port** number used by your server (Port 587 is most common).
4. Provide an authorized **SMTP Username** and **SMTP Password** for your server.
5. By default, **Enable STARTTLS** is always **True** to ensure encrypted communication.
6. Select the **SMTP Authentication Method** that matches your server setup: either **PLAIN** or **LOGIN**.
7. Click **Save** to apply the SMTP settings to your automated email action.
8. Validate the SMTP by using the **Run** feature within the playbook to ensure it is properly configured.

### Email Templates

To make setting up emails easier, Zscaler MDR provides several pre-built templates that you can choose from, saving you time and ensuring consistency. Below is a summary of the available templates:

#### Custom Freeform Email

This template is a completely freeform email. Enter text in the Message field and you will receive an email with exactly that.

Here’s an example:

![](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/image(386).png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A14Z&se=2026-11-09T12%3A54%3A14Z&sr=c&sp=r&sig=buaJkfeobNTTTxl41MczqpqCjHMoKh12TaemI9Zzpr4%3D)

Which produces this email:

![](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/image(387).png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A14Z&se=2026-11-09T12%3A54%3A14Z&sr=c&sp=r&sig=buaJkfeobNTTTxl41MczqpqCjHMoKh12TaemI9Zzpr4%3D)

#### Custom Freeform Email with Markdown Rendered into HTML

This template is similar to the Custom Freeform Email but allows you to use Markdown, which will be converted into HTML format for enhanced formatting options.

Here’s an example:

![](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/addautomateactions-1_03.png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A14Z&se=2026-11-09T12%3A54%3A14Z&sr=c&sp=r&sig=buaJkfeobNTTTxl41MczqpqCjHMoKh12TaemI9Zzpr4%3D)

Which produces this email:

![](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/image(373).png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A14Z&se=2026-11-09T12%3A54%3A14Z&sr=c&sp=r&sig=buaJkfeobNTTTxl41MczqpqCjHMoKh12TaemI9Zzpr4%3D)

#### Threat: All Threat Data as JSON

This template is designed for systems that read structured JSON data from emails; ServiceNow is a common recipient for these messages. The associated threat is sent in JSON format in the email body.

Here’s an example:

![](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/image(374).png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A14Z&se=2026-11-09T12%3A54%3A14Z&sr=c&sp=r&sig=buaJkfeobNTTTxl41MczqpqCjHMoKh12TaemI9Zzpr4%3D)

Which produces this email:

![](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/image(375).png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A14Z&se=2026-11-09T12%3A54%3A14Z&sr=c&sp=r&sig=buaJkfeobNTTTxl41MczqpqCjHMoKh12TaemI9Zzpr4%3D)

#### Threat: Published Notification in HTML

This template sends information about a threat to users in a condensed, summary format that includes a brief list of identified Indicators of Compromise (IOCs).

Here’s an example:

![](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/image(384).png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A14Z&se=2026-11-09T12%3A54%3A14Z&sr=c&sp=r&sig=buaJkfeobNTTTxl41MczqpqCjHMoKh12TaemI9Zzpr4%3D)

Which produces this email:

![](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/image(385).png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A14Z&se=2026-11-09T12%3A54%3A14Z&sr=c&sp=r&sig=buaJkfeobNTTTxl41MczqpqCjHMoKh12TaemI9Zzpr4%3D)

#### Threat: Human-readable HTML with full timeline

This template sends information about a threat to users in a condensed, summary format with the complete timeline of the threat, including all relevant activity and identified Indicators of Compromise (IOCs).

Here’s an example:

![](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/image(382).png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A14Z&se=2026-11-09T12%3A54%3A14Z&sr=c&sp=r&sig=buaJkfeobNTTTxl41MczqpqCjHMoKh12TaemI9Zzpr4%3D)

Which produces this email:

![](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/image(383).png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A14Z&se=2026-11-09T12%3A54%3A14Z&sr=c&sp=r&sig=buaJkfeobNTTTxl41MczqpqCjHMoKh12TaemI9Zzpr4%3D)

> [!NOTE]
> **Note**
> 
> Threat email message templates are only valid when used with threat-based triggers.

## Add a Slack Response Action

Integrating with Slack allows Zscaler MDR to send Slack messages as part of an automation playbook.

> [!NOTE]
> Note
> 
> You will need to update your webhooks on both the Zscaler MDR and Slack side once Slack sunsets their legacy webhook feature. Zscaler MDR will develop new documentation once this event happens in Slack.

### Configure Slack to Accept an Incoming Webhook

1. Go to [Slack-Incoming webhook](https://my.slack.com/services/new/incoming-webhook/).
2. Select the channel you want messages posted in and then click **Add Incoming WebHooks integration**.
3. Copy the webhook URL.

### Add a Slack Notification to an Automation Playbook

1. Within any playbook, click **Add Action**.
2. Click **Slack**, **Send Slack Message** and then click **Add to Playbook**.
3. Paste your webhook URL in **Slack Webhook URL**.
4. Specify the **Channel** where messages should be posted.
5. Specify the title you want to appear for each message, using interpolated values for customization.
6. Optionally, specify a **Title Link** as the URL the message should link to when clicked.
7. Select one of the Slack-supported colors for the left stripe of the message.
8. Optionally, specify custom fields that should appear in the message body.
9. Click **Save**.

## Add a SMS Response Action

1. In any playbook, click **Add Action**.
2. Click **SMS** and then click **Send SMS** **Message**.
3. Click **Add to Playbook**.
4. Enter one or more comma-separated phone numbers that should receive the SMS message. Use the complete '+' and country code, for example: +16175551212.

You can change the phone number dynamically using variables. For example, you can use the variable `$Detection.marked_acknowledged_by_user.phone` to message the user who acknowledged a threat.
5. Enter the message you want to send.

![Send SMS.png](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/12605289511703.png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A14Z&se=2026-11-09T12%3A54%3A14Z&sr=c&sp=r&sig=buaJkfeobNTTTxl41MczqpqCjHMoKh12TaemI9Zzpr4%3D)
6. Click **Save**.

When the playbook is triggered, Zscaler MDR will send your message to the specified phone number.

![mceclip1.png](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/l9xol6rmf0atkcmwxt3u7gmceclip1.png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A14Z&se=2026-11-09T12%3A54%3A14Z&sr=c&sp=r&sig=buaJkfeobNTTTxl41MczqpqCjHMoKh12TaemI9Zzpr4%3D)

### What if SMS messages are not being delivered?

SMS delivery is carrier and phone dependent, so exercise caution when entering certain Unicode or reserved characters, or interpolating with fields that might contain special characters like filenames.

### What if I do not receive the messages?

Be sure to check your Spam or Junk folder, and then troubleshoot as necessary by adjusting message contents or sending to a different number or carrier.

Zscaler MDR uses a highly reliable service provider to deliver SMS codes through carriers around the world. Almost all cases of messages not being delivered are the result of a carrier blocking certain messages. Check your phone or carrier's **unknown SMS** or **spam SMS** blocking settings.

Zscaler MDR’s syslog integration allows you to send syslog messages to a syslog receiver as part of an automation playbook.

The most common use of the syslog action is sending data to a SIEM or log collection platform, though we recommend using webhooks whenever possible because they are more modern, customizable, and reliable.

## Add a Syslog Response Action

1. Within any playbook, click **Add Action**.
2. Click **Syslog** and then click **Send Syslog** Message.
3. Click **Add to Playbook**.
4. Specify the **Server Domain/IP** that is configured to receive messages. If you use source restriction, the IP addresses from which communications must be authorized are listed.
5. Specify the **Server Port** that messages should be sent to.
6. Specify whether connections to untrusted servers will be allowed or not.
7. Select the protocol for sending.
8. Select the **Syslog Program**, **Syslog Facility,** and **Syslog Severity** that you want messages from Zscaler MDR to use.
9. Specify the syslog **Message** that you want sent to the syslog receiver.
10. Click **Save**.

### What if my syslog server doesn’t support TLS/SSL?

Be very careful about the security of any application that is exposed to the internet. At a minimum, use IP source restrictions to only allow traffic from trusted sources (the IP addresses used by Zscaler MDR are specified on the syslog action configuration form).

To disable Zscaler MDR’s TLS/SSL requirement, set the **Protocol** to TCP or UDP.

Zscaler MDR’s webhook integration allows you to trigger any HTTP listener as part of an automation playbook. Common uses of webhooks include the following:

- Creating tickets in ticket-tracking systems such as ServiceNow or JIRA.
- Posting data to Security information and event management (SIEM) / log collection platforms like Splunk or SumoLogic.
- Triggering incidents in paging systems such as OpsGenie or VictorOps (PagerDuty has a distinct integration action).
- Sending data to a custom business application you have exposed to the internet as custom software, an Azure function, or an AWS endpoint.

Webhooks are highly customizable and allow you to configure which HTTP method is used and specify HTTP headers that are used for authorization, routing, and so on.

## Add a Webhook Response Action

1. Within any playbook, click **Add Action**.
2. Click **Webhook/API** and then click **Invoke Webhook or** API.
3. Click **Add to Playbook**.
4. Select an **HTTP Method** that should be used.
5. Enter the **URL** that should be invoked.
6. Optionally, enter one or more HTTP headers that should be included in the HTTP request.

> **Note:** By default, no HTTP headers are sent.
7. Specify a **Payload** type (learn more about these below).

> **Note:** Payloads are applicable to the POST, PUT, and PATCH HTTP methods.
8. Click **Save**.

> [!NOTE]
> Note
> 
> For Splunk, a HTTP Event Collector (HEC) token is required in the HTTPS Headers section, with this format: Authorization= Splunk [token]

> [!NOTE]
> Note
> 
> Related IP addresses for webhooks and other Transmission Control Protocol (TCP) ingress are provided on your Getting Help page.

### What are payloads?

A webhook’s payload is the content contained in the body of the HTTP request to the specified URL. These payloads can be customized based on your needs and the API you’re integrating with.

#### All Attributes as JSON

This payload type sends all of the objects and attributes that triggered the action to the webhook URL as the body of a JSON post.

If the receiving application requires the *Content-Type* header to properly process the message, ensure you specify **Content-Type=application/json** in the **HTTP Headers** section.

#### Custom Payload

This payload type allows you to specify a fully custom webhook payload. This content can be JSON, text, and so on.

If required by the receiving application, ensure you send the appropriate HTTP headers using the **HTTP Headers** section.

#### What happens if my payload fails?

If your application returns an HTTP status code other than 200, we will send an email to your technical contacts with details about the failure to assist you in troubleshooting.

To prevent flooding your inbox, we will send only one Webhook Failure email per playbook every 24 hours. In addition to this, we will create an Audit Log with **Action: Automate Action Executed**, and include details about the error in the Details section. We will create this AuditLog every time the Webhook fails. At the moment, we do not allow these AuditLogs to trigger playbooks.