Creating Datto EDR webhooks

NAVIGATION   > Admin > Webhooks

SECURITY   Service account or administrator-level rights on the target endpoint

You can configure Datto EDR to send webhook notifications to any platform that can receive them. This article explains how to create and configure them.

NOTE  For information about how to receive webhook notifications in a third-party application, contact the corresponding vendor for support.

About webhooks

Webhooks are an efficient way to exchange information between applications.

Traditional API calls provide information in response to a query. To get updated information via an API call, you must keep polling the application.

EXAMPLE  "Were any new threats detected in my environment since the last query?
Were any new threats detected in my environment since the last query?
Were any new threats detected in my environment since the last query?..."

Imagine that only 2% of the time, you receive a positive answer. All that network traffic, so little to show for it.

Webhooks, on the other hand, work on a "Don't call me, I'll call you if I have something new" basis. The server-side application calls the client-side application (by invoking a client-provided webhook URL) any time that the server-side has something new to report to the client. When an event happens, a notification routes to any registered subscribers in the form of an HTTP POST request. The information (or 'payload') arrives in JSON format on port 443.

EXAMPLE  "An audit revealed a new threat in your environment, and here is the endpoint name, IP address, threat type, reputation information, and risk."

You can use webhooks to notify you of nearly all of the same information you can find on the Alerts page in the EDR UI, including the following critical data points:

  • Originating EDR instance of the alert
  • Threat type
  • Threat weight
  • Impacted hostname
  • File name of the threat object
  • Malicious or non-malicious

You can also use external ID fields or user-defined reference fields for reliable data mapping. You can always include them in the payload, even if you have not updated them.

Datto EDR webhooks can and should be created by administrators and vendors who are building integrations with the platform, and vendors who are building connectors to middleware products.

Using webhooks instead of regular API calls can lead to a significant reduction in the number of inbound calls against our API platform, which will increase performance for all API users. But there are significant advantages for the integration developer as well. Webhooks enable you to design applications differently than a polling application, and you can often implement them with less coding. Webhooks for actions like creating and updating can be specific to that action. With the polling approach, code must handle checking for a large number of records, often caching data and comparing fields to determine what has changed. With webhooks, developers can build integrations faster and for a lower cost.

Additional advantages:

  • Near real-time notifications: The speed with which you can discover that a threat was detected can be limited by polling time intervals. Webhooks provide almost instantaneous notification of threat activity.
  • Reduced risk of hitting API thresholds: Your risk of reaching any applicable maximum API call thresholds becomes reduced without the need to do polling.

Prerequisites

Before you can use webhooks, you'll need to ensure that the following prerequisites are met.

Your company will need to set up the following pieces of infrastructure:

  • A web service that will receive and process any webhook callouts from Autotask.
  • A webhook URL to which the webhook payload will post.

Both items are required to create webhooks.

NOTE  You can use a service like RequestBin.com while you are creating and testing your webhooks.

Datto EDR can send extensive amounts of detail about each threat it identifies. You'll construct your alerts by using body variables. Determine the level of information you'd like to send to your recipient platform in each alert and how you will parse that information. A complete list of supported body variables is available at the bottom of the > Admin > Webhooks > Add Webhook page.

Getting started

To create webhooks, perform the following steps:

  1. Within the EDR platform, navigate to > Admin > Webhooks.

  2. Click Add Webhook.

  3. The Add Webhook modal will open. Complete the following fields.

Field name Definition
Name

Enter a human-readable name for the webhook. This name will appear in the list at > Admin > Webhooks.
Description (optional)

Provide a description of the webhook's purpose. This information is useful to system administrators that are managing multiple notifications.
URL

Input the URL to which the webhook payload will post.
Headers

Specify any necessary headers that this webhook may need to use when communicating with your web service. Separate multiple values with a comma and no space.
Accept self-signed certificates

Certificates authenticate a site as secure. Self-signed certificates are intended for testing websites and intranet sites. Trusted certificates are used for public websites. Activating this toggle disables our trusted check.
Include observable events

Select this option to also send observable events as webhook alerts, which are non-alerting behaviors detected by Datto EDR. Note that activating this option will increase the number of alerts you receive. Before doing so, we recommend reviewing the alert table to determine how many non-alert detections you receive to better understand the potential increase in volume.

  1. Click Save to create the webhook. It will appear in the list on the Webhooks page.

    NOTE  If your application is having trouble receiving events from Datto EDR, click View Errors from the menu to troubleshoot the issue.

The following fields are automatically included in the body of your webhook payload.

Variable name Definition

{{avPositives}}

The number of threat intelligence positive hits for the object

{{avTotal}}

Total threat intelligence results found for the object

{{blacklist}}

Indicates if the object is globally blocklisted

{{createdOn}}

The time and date that the alert was created

{{fileRepId}}

ID of the file rep object

{{flagColor}}

Color of the flag attached to the object

{{flagId}}

ID of the flag attached to the object

{{flagName}}

Name of the flag attached to the object

{{flagWeight}}

Weight of the flag attached to the object

{{hasAvScan}}

Indicates whether the object has threat intelligence data
{{hostname}}

Assigned hostname of the endpoint

{{hostScanId}}

ID of the host in a particular scan

{{id}}

ID of the specific alert

{{instance}}

Name of the EDR instance from which the alert originated

{{itemId}}

ID of the object

{{link}}

URL link to the object

{{localBlacklist}}

Indicates if the object is locally blocklisted

{{localWhitelist}}

Indicates if the object is locally allowlisted

{{malicious}}

Indicates whether the object is malicious

{{managed}}

Indicates whether the object is managed

{{name}}

Filename for most file-based objects, the hash of the memory content for memory injections, and the username for accounts

{{notMalicious}}

Indicates if the object is non-malicious

{{scanId}}

ID of the scan

{{severity}}

Severity of the source, if one exists

{{signed}}

Indicates whether the object is signed

{{sourceId}}

ID of the source, if one exists

{{sourceName}}

Name of the source, if one exists

{{staticAnalysis}}

Static analysis data for the object (JSON object)

{{suspicious}}

Indicates whether the object is suspicious

{{synapse}}

Synapse score of the object

{{targetGroupId}}

UUID of the location from which the alert originated

{{threatName}}

Name of the threat level on the object

{{threatScore}}

A numeric score on a scale of zero to 10 indicating confidence, with zero being definitely good and 10 being definitely bad

{{threatWeight}}

EDR's assessment of the risk level of the object; when associated with a host, indicates whether or not the endpoint appears to have been compromised

{{type}}

The source of the forensic artifact; Shimcache and Amcache appear frequently along with process arguments (a reference to an executable that the audit found referenced in a process's command-line arguments)

{{unknown}}

Indicates if the object threat is unknown

{{whitelist}}

Indicates if the object is globally allowlisted