EDR Integrations

Caution

The EDR UI — the /security/edr fleet page, the Security-tab EDR panel on device pages, and the Security dashboard summary cards — is hidden by default. It is surfaced only when the web image is built with the environment variable PUBLIC_ENABLE_EDR_INTEGRATIONS=true. This is a build-time web flag: the value is baked into the web bundle at image-build time and cannot be toggled at runtime via .env. The API sync jobs and all EDR endpoints operate regardless of this flag.

Breeze integrates with leading Endpoint Detection and Response (EDR) platforms to give you a unified view of endpoint security across your managed fleet. Instead of switching between your RMM and EDR consoles, you can view threat data, agent coverage, and incident details directly in Breeze.

Currently supported EDR vendors:

Vendor	Data Synced	Actions Available
Huntress	Agents, incidents	Webhook ingestion, manual sync
SentinelOne	Agents, threats, site mappings	Device isolation, threat actions (kill, quarantine, rollback), manual sync

Both integrations are configured once at the partner level: with your scope selector set to All orgs you provide the vendor’s API credentials, map each vendor’s organizations/sites to your Breeze organizations, and Breeze syncs agent and threat data on a schedule. The synced data is attributed to the correct customer and matched to your existing Breeze devices.

Auto-Linking: How EDR Agents Map to Breeze Devices

During each sync, Breeze automatically attempts to match imported EDR agents to enrolled Breeze devices. The matching logic differs slightly by vendor:

Huntress: Agents are matched by hostname (case-insensitive, trimmed). Breeze compares the Huntress agent’s hostname against both the hostname and displayName of every enrolled device in the organization. If a match is found, the Huntress agent and any associated incidents are linked to that Breeze device.

SentinelOne: Agents are matched first by hostname (the computerName field), then by IP address as a fallback. If the SentinelOne agent’s computer name matches a Breeze device hostname (case-insensitive), the match is made. If no hostname match exists, Breeze checks the agent’s network interfaces against known device IP addresses.

Agents that cannot be matched appear as “unmapped” in the integration status dashboard. To resolve unmapped agents, either enroll the missing device in Breeze or verify that the hostname in the EDR system matches the hostname reported by the Breeze agent.

---

Huntress

Overview

The Huntress integration syncs agent inventory and incident reports from your Huntress account into Breeze. It supports both pull-based syncing (via the Huntress API) and push-based updates (via webhooks). Huntress agents are automatically matched to Breeze devices, and incidents are linked to the affected device when a mapping exists.

Setting Up Huntress

1. Set your scope selector to All orgs, then navigate to Integrations, open the Security tab, and select Huntress. Huntress is configured once for the whole partner.
2. Provide a name for the integration (e.g., “Production Huntress”).
3. Enter your Huntress API Key and API Secret as shown in the Huntress portal. Paste each value into its own field — do not paste a Base64-encoded combination of the two; Breeze formats the API request automatically. Both values are encrypted at rest using AES before being stored.
4. Enter your Deployment Account Key. This key is found on the Huntress agent-download page in your Huntress portal and is required to enable one-click Huntress deployment from Breeze’s Software → Deployment catalog.
5. Optionally provide your Huntress account ID. (A custom API base URL can be set via the Breeze API; the default is https://api.huntress.io/v1.)
6. Optionally provide a webhook secret for signature verification on incoming webhook payloads.
7. Click Save & Connect. An initial sync is automatically scheduled.

Note

The Huntress integration is configured at the partner level — one Huntress account serves all of your customer organizations. Configure it with your scope selector set to All orgs; the connection and credential fields are only available in that view. You then map each Huntress organization to a Breeze organization (see Organization Mappings below). Organization users can view the agents and incidents for their mapped org but cannot change the connection or mappings.

Note

Creating or updating a Huntress integration requires the orgs:write permission and MFA verification.

Webhook Configuration

Huntress can push event notifications to Breeze in real time via webhooks.

Getting the webhook URL and secret from Breeze

You no longer need to hand-build the webhook URL. With your scope set to All orgs, open Integrations > Security > Huntress. Once the integration is connected, the Inbound webhook section shows:

1. The exact, region-correct Webhook URL to paste into Huntress, with a Copy button. The URL includes an integrationId query parameter that tells Breeze which partner the events belong to — keep it in the URL.
2. A Webhook Secret field with a Generate button. Click Generate to create a strong secret, copy it (it is shown only once), paste the same value into Huntress’s webhook configuration, then Save to store it. Breeze keeps it encrypted and never displays it again.

The webhook URL has the form:

POST https://your-breeze-instance.com/api/v1/huntress/webhook?integrationId=<id>

Webhook payloads are verified using HMAC-SHA256 signature validation:

1. Breeze reads the signature from the x-huntress-signature header (fallback: x-signature).
2. Breeze reads the timestamp from the x-huntress-timestamp header (fallback: x-timestamp).
3. Breeze computes HMAC-SHA256(secret, "{timestamp}.{body}") and compares the result to the provided signature using a timing-safe comparison.
4. The timestamp must be within 10 minutes of the current server time, or the webhook is rejected as a potential replay.

The expected signature format is sha256={hex_digest}.

Caution

Webhook signature verification is mandatory. If no webhook secret is configured for the integration, all incoming webhooks are rejected with a 403 error. Always configure a webhook secret when enabling webhook ingestion.

Webhook Routing

When Breeze receives a Huntress webhook, it needs to determine which integration the event belongs to. The integration is resolved using (in order of priority):

1. integrationId query parameter or x-huntress-integration-id header
2. integrationId field in the JSON payload body
3. x-huntress-account-id header or account ID extracted from the payload

If multiple active integrations match the same account and no explicit integration ID is provided, the webhook returns a 409 conflict.

Organization Mappings

Because the Huntress integration is partner-scoped, Breeze discovers the organizations in your Huntress account during each sync and lets you map each one to a Breeze organization. Mapping an organization attributes its agents and incidents to the correct customer, so organization users only see their own data.

1. With your scope selector set to All orgs, open Integrations > Security > Huntress and find the Organization mapping section.
2. Review the list of Huntress organizations discovered during sync, each shown with its agent and incident counts.
3. For each Huntress organization, select the Breeze organization it should map to.
4. The mapping saves immediately. Agents and incidents from that Huntress organization are attributed to the selected Breeze organization.

To remove a mapping, clear the selected Breeze organization. Unmapped Huntress organizations remain visible in the partner view, but their agents and incidents are no longer attributed to a specific customer.

Data Model (For Integrators)

Huntress Agents

Field	Type	Description
huntressAgentId	String	Unique agent identifier from Huntress
deviceId	UUID	Mapped Breeze device (nullable if unmapped)
hostname	String	Agent hostname
platform	String	Operating system platform
status	String	Agent status (e.g., online, offline)
lastSeenAt	Timestamp	Last time the agent checked in with Huntress
metadata	JSON	Additional agent metadata from Huntress

Huntress Incidents

Field	Type	Description
huntressIncidentId	String	Unique incident identifier from Huntress
deviceId	UUID	Affected Breeze device (nullable if unmapped)
severity	String	Incident severity level
category	String	Incident category (max 60 chars)
title	String	Incident title
description	Text	Detailed incident description
recommendation	Text	Recommended remediation steps
status	String	Current incident status
reportedAt	Timestamp	When the incident was first reported
resolvedAt	Timestamp	When the incident was resolved (nullable)
details	JSON	Full incident details from Huntress

Status Dashboard

The Huntress status endpoint provides a summary of your integration health:

Metric	Description
totalAgents	Total Huntress agents synced
mappedAgents	Agents matched to Breeze devices
unmappedAgents	Agents without a Breeze device match
offlineAgents	Agents with an offline status
open	Count of unresolved incidents
bySeverity	Incident counts grouped by severity
byStatus	Incident counts grouped by status

Listing Incidents

Incidents can be filtered by multiple criteria:

Filter	Type	Description
orgId	UUID	Filter by organization
integrationId	UUID	Filter by specific integration
status	String	Filter by incident status
severity	String	Filter by severity level
deviceId	UUID	Filter by affected Breeze device
search	String	Search incident titles (case-insensitive)
limit	Number	Results per page (1-500, default 100)
offset	Number	Pagination offset

---

SentinelOne

Overview

The SentinelOne integration provides deeper operational capabilities beyond data sync. In addition to importing agent and threat data, you can isolate devices and take threat actions (kill, quarantine, rollback) directly from the Breeze dashboard – commands are dispatched to the SentinelOne management console via API.

Setting Up SentinelOne

1. Set your scope selector to All orgs, then navigate to Integrations, open the Security tab, and select SentinelOne. SentinelOne is configured once for the whole partner.
2. Provide a name for the integration.
3. Enter your SentinelOne management console URL (e.g., https://usea1.sentinelone.net).
4. Enter your SentinelOne API token. This is encrypted at rest before being stored.
5. Click Save & Connect. An initial sync is automatically scheduled.

Note

The SentinelOne integration is configured at the partner level — one SentinelOne tenant serves all of your customer organizations. The connection and credential fields are only available with your scope selector set to All orgs. You then map each SentinelOne site to a Breeze organization (see Site Mappings below). Organization users can view the threats and agents for their mapped org but cannot change the connection or mappings.

Note

Creating or updating a SentinelOne integration requires the orgs:write permission and MFA verification. Only one active SentinelOne integration is allowed per partner.

MFA Requirements by Operation

The following SentinelOne operations require MFA verification before they can be executed:

Operation	MFA Required
Create or update integration	Yes
Isolate / unisolate devices	Yes
Execute threat actions (kill, quarantine, rollback)	Yes
Trigger manual sync	No
View status, threats, or sites	No

Data Model (For Integrators)

SentinelOne Agents

Field	Type	Description
s1AgentId	String	Unique agent identifier from SentinelOne
deviceId	UUID	Mapped Breeze device (nullable if unmapped)
status	String	Agent connection status
infected	Boolean	Whether the agent has active threats
threatCount	Integer	Number of threats detected on this agent
policyName	String	Applied SentinelOne policy name
lastSeenAt	Timestamp	Last check-in time
metadata	JSON	Additional agent metadata including site name

SentinelOne Threats

Field	Type	Description
s1ThreatId	String	Unique threat identifier from SentinelOne
deviceId	UUID	Affected Breeze device (nullable if unmapped)
classification	String	Threat classification (e.g., Malware, PUP)
severity	String	Severity level (low, medium, high, critical)
threatName	String	Name of the detected threat
processName	String	Process that triggered the detection
filePath	String	File path of the threat
mitreTactics	JSON	MITRE ATT&CK tactic mappings
status	String	Current threat status (active, in_progress, resolved, etc.)
detectedAt	Timestamp	When the threat was first detected
resolvedAt	Timestamp	When the threat was resolved (nullable)
details	JSON	Full threat details from SentinelOne

SentinelOne Actions

Field	Type	Description
action	String	Action type (isolate, unisolate, kill, quarantine, rollback)
status	String	Action status: queued, in_progress, completed, failed
providerActionId	String	Action ID from SentinelOne API
requestedBy	UUID	User who initiated the action
requestedAt	Timestamp	When the action was requested
completedAt	Timestamp	When the action finished (nullable)
error	Text	Error message if the action failed

Site Mappings

SentinelOne organizes agents into “Sites.” Breeze lets you map SentinelOne sites to Breeze organizations, enabling multi-tenant EDR management from a single SentinelOne console.

1. With your scope selector set to All orgs, open Integrations > Security > SentinelOne and find the Site mapping section.
2. Review the list of discovered SentinelOne sites, each shown with its agent count.
3. For each SentinelOne site, select the Breeze organization it should map to. Unmapped sites stay quarantined — their agents and threats are not attributed to any customer — until assigned.
4. The mapping saves immediately.

To remove a mapping, clear the selected Breeze organization.

Device Isolation

You can isolate compromised devices directly from Breeze. The isolation command is sent to SentinelOne, which enforces network isolation at the endpoint level.

1. Select one or more devices in the Breeze dashboard.
2. Click Isolate (or Unisolate to restore connectivity).
3. Breeze identifies the corresponding SentinelOne agents and dispatches the isolation command.
4. The action status is tracked and reported back.

Caution

Device isolation requires the devices:execute permission and MFA verification. You can isolate up to 200 devices in a single request.

Threat Actions

Take direct action on detected threats without leaving Breeze:

Action	Description
kill	Terminate the malicious process
quarantine	Move the threat file to quarantine
rollback	Roll back changes made by the threat (Windows only)

1. Navigate to the Threats view and find the threat(s) to act on.
2. Select the threat action (kill, quarantine, or rollback).
3. Confirm the action. Up to 200 threats can be acted on in a single request.
4. The action is dispatched to SentinelOne and the status is tracked.

Caution

Threat actions require the devices:execute permission and MFA verification.

Status Dashboard

The SentinelOne status endpoint provides a comprehensive summary:

Metric	Description
totalAgents	Total SentinelOne agents synced
mappedDevices	Agents matched to Breeze devices
infectedAgents	Agents with active infections
activeThreats	Threats with active or in_progress status
highOrCriticalThreats	Threats with high or critical severity
pendingActions	Actions with queued or in_progress status
reportedThreatCount	Sum of threat counts across all agents

Listing Threats

Threats can be filtered by multiple criteria:

Filter	Type	Description
orgId	UUID	Filter by organization
integrationId	UUID	Filter by specific integration
deviceId	UUID	Filter by affected Breeze device
status	String	Filter by threat status
severity	String	Filter by severity level
search	String	Search by threat name, process name, or file path
start	ISO datetime	Threats detected on or after this time
end	ISO datetime	Threats detected on or before this time
limit	Number	Results per page (1-500, default 100)
offset	Number	Pagination offset

---

Promote to Incident

From the /security/edr fleet page or from a device’s Security tab, you can escalate a Huntress incident or a SentinelOne threat directly into a tracked Breeze incident. Click Promote to incident on the item, confirm the pre-filled title and severity (mapped from the EDR severity level), and Breeze creates the incident and navigates you to it. The promotion records the source (Huntress or SentinelOne), the original title, any affected device, and the detection time as the incident’s detected-at timestamp.

Promotion uses the standard POST /incidents endpoint and follows normal incident-creation permissions.

---

Deploying EDR Agents

Once a Huntress or SentinelOne integration is connected, both vendors appear as built-in deployment packages under Software → Deployment. You can push the EDR agent to any managed device — or group of devices — with a single click, without leaving Breeze.

Huntress

Huntress deployment is fully built in: no binary upload is required. Breeze uses the Deployment Account Key you entered during integration setup to generate and deliver the Huntress installer to the target device. Simply navigate to Software → Deployment, select Huntress from the catalog, choose your target devices, and click Deploy.

SentinelOne

SentinelOne deployment requires a one-time setup step: upload the SentinelOne MSI to the deployment catalog before pushing it to devices.

1. Download the SentinelOne Windows MSI from your SentinelOne management console.
2. Navigate to Software → Deployment in Breeze and open the SentinelOne catalog entry.
3. Upload the MSI using the Upload package option.
4. Select your target devices and click Deploy.

Once the MSI is uploaded, subsequent deployments to new devices re-use the same package — you only need to re-upload when SentinelOne releases a new installer version.

Automating EDR deployment

Both Huntress and SentinelOne deployment packages can also be driven through Automations using the Deploy Software action type. This lets you automatically push an EDR agent to newly enrolled devices by pairing a Device Enrolled event trigger with a Deploy Software action targeting the relevant catalog item.

---

Syncing

Both integrations support manual and automatic syncing.

Manual Sync

Trigger a sync from the Breeze dashboard or API. The sync job is queued via the background queue and processes in the background.

Vendor	Requirements
Huntress	orgs:write permission, MFA, active integration
SentinelOne	orgs:write permission, active integration

Sync Status

Each integration tracks its last sync result:

Field	Description
lastSyncAt	Timestamp of the most recent sync
lastSyncStatus	Result: success or failure indicator
lastSyncError	Error message from the last failed sync (nullable)

After you click Sync Now for Huntress, Breeze polls the integration and shows the live status (Syncing → Connected/Error). On success it reports the result counts (for example, agents, incidents, and organizations synced); on failure it shows the actual error from the last run rather than a generic “triggered” message.

Sync Error Handling and Retries

Sync jobs are processed through a background queue. If a sync fails (for example, due to a network timeout or an API rate limit from the EDR vendor), the following happens:

• SentinelOne syncs automatically retry up to 3 times with exponential backoff (starting at 2 seconds, then 4 seconds, then 8 seconds).
• Huntress syncs automatically retry up to 3 times with exponential backoff, so a transient failure (network timeout, rate limit, or a temporary database connection drop) recovers without operator intervention. The integration’s live status and the last run’s result counts are surfaced in the dashboard so you can see whether the most recent sync succeeded.
• The lastSyncError field on the integration record is updated with the error message from the most recent failure. Check this field in the dashboard or API to diagnose sync issues.
• If the initial sync scheduled on integration creation fails, a warning is returned in the API response: “Initial sync could not be scheduled. Data will sync on the next scheduled cycle.”

---

API Reference

Huntress

All authenticated endpoints require organization, partner, or system scope. Mounted at /api/v1/huntress.

Method	Path	Auth	Description
POST	/webhook	No (signature verified)	Receive Huntress webhook events
GET	/integration	Yes	Get the Huntress integration for the current org
POST	/integration	Yes + MFA	Create or update a Huntress integration
POST	/sync	Yes + MFA	Trigger a manual Huntress sync
GET	/status	Yes	Get integration status and coverage summary
GET	/incidents	Yes	List Huntress incidents with filters

SentinelOne

All endpoints require authentication. Credentials and mappings are managed at partner scope; organization-scoped users get read-only access to their mapped data and a 403 on credential or mapping changes. The partner is resolved from the caller’s token; system-scope callers pass an optional partnerId query parameter. Mounted at /api/v1/s1.

Method	Path	Auth	Description
GET	/integration	Yes	Get the partner’s SentinelOne integration
POST	/integration	Yes + MFA (partner)	Create or update the SentinelOne integration
GET	/status	Yes	Get integration status and threat summary
GET	/threats	Yes	List threats with filters
POST	/isolate	Yes + MFA	Isolate or unisolate devices
POST	/threat-action	Yes + MFA	Execute a threat action (kill, quarantine, rollback)
POST	/sync	Yes	Trigger a manual SentinelOne sync
GET	/sites	Yes	List SentinelOne sites with agent counts and org mappings
POST	/organizations/map	Yes (partner)	Map or unmap a SentinelOne site to a Breeze organization ({ integrationId, s1SiteId, orgId })

---

Automation Events

Both integrations emit platform events that can trigger automations and outbound webhooks. Select these event types in the automation builder (Automations > Create > Event trigger) to react to security activity — for example, creating a ticket when a critical incident is reported, or notifying the on-call channel when an endpoint is isolated.

Event type	Fires when
huntress.incident_created	A new Huntress incident is synced or received via webhook
huntress.incident_updated	An existing incident changes severity, status, or resolution
huntress.agent_offline	A Huntress agent transitions from online to offline
s1.threat_detected	A new SentinelOne threat is detected
s1.device_isolated	A device isolation initiated from Breeze completes in SentinelOne
s1.threat_action_completed	A threat action initiated from Breeze (kill, quarantine, rollback) completes

---

Security

Credential Storage

API keys and tokens for both Huntress and SentinelOne are encrypted at rest using AES encryption before being stored in the database. The apiKeyEncrypted and apiTokenEncrypted fields are never returned in API responses – only a boolean hasApiKey or similar flag is exposed.

Webhook Verification

Huntress webhooks use HMAC signature verification. The webhook secret is encrypted at rest and decrypted only at verification time. Webhooks without a configured secret or with an invalid signature are rejected.

Permission Requirements

Operation	Required Permission	MFA Required
View integration status	organization, partner, or system scope	No
Create/update integration	orgs:write	Yes
Trigger manual sync	orgs:write	Huntress: Yes, SentinelOne: No
Isolate devices	devices:execute	Yes
Execute threat actions	devices:execute	Yes

---

Troubleshooting

Sync shows “Integration is inactive”

Activate the integration by updating it with isActive: true before triggering a sync.

Huntress webhook returns 403 “Webhook secret not configured”

You must configure a webhook secret on the integration before Breeze will accept webhook payloads. Update the integration with a webhookSecret value that matches what you configured in your Huntress dashboard.

Huntress webhook returns 409 “Multiple active integrations match”

When multiple Huntress integrations share the same account ID, Breeze cannot determine which one to route the webhook to. Include the integrationId as a query parameter on your webhook URL or in the x-huntress-integration-id header.

SentinelOne isolation returns 502

A 502 response means the isolation command was sent to SentinelOne but the provider returned an error. Check the warning field in the response for details and verify the target devices have active SentinelOne agents.

Unmapped agents

After syncing, some EDR agents may not be matched to Breeze devices. This happens when the hostname or identifier in the EDR system does not correspond to any enrolled Breeze device. Enroll the missing devices in Breeze or verify the hostname matches.

“API token is required for new integrations”

When creating a new SentinelOne integration, the API token is mandatory. For updates to existing integrations, the token is optional (the existing encrypted token is preserved).