Integrations, Webhooks, APIs

We are working with Rewst for process automation. It'd be great to be able to uninstall agents via API, create/delete users, isolate machines, etc..

We use a custom browser plugin to pop alert banners when things need attention in Huntress. This works really well for all team members when it comes to incidents but when it comes to escalations there doesn't seem to be any way to review/check for these under the API.

Allow the uninstall of Huntress agents via API request. Since tamper protection has been introduced to the Huntress agent, enabling the feature means RMMs can no longer automatically uninstall Huntress from a device. Without an API endpoint to trigger an uninstall, this breaks automation processes and adds new manual tasks that can only be completed in the Huntress portal.

I need to access SIEM data through the API, but it seems that this data is not yet available. Having access to SIEM data via the API would be crucial for my operations, as it is more important to me than other data types.

When attempting to correlate the devices in the Huntress portal against the devices in Datto RMM that show Huntress is installed, there is a disconnect. It's impossible to have a 1:1 correlation between the two portals. If I have 800 devices in Datto RMM that show Huntress is installed, and the Huntress portal shows 810 devices, how do I reconcile that? It's impossible to handle programmatically. Manually reviewing orgs and devices doesn't scale. There needs to be a way to quickly reconcile the two platforms and confirm with 100% certainty which devices in one platform link with the other. The absolute best way to handle this is to utilize Datto RMM's device ID as a tag during the installation process. This tag would get saved in the Huntress portal and would identify each device uniquely. From here, we could run a script against the APIs of both platforms and easily identify which devices don't match, which have duplicates and which might require further investigation. To make this work, I've added a bit of code to the Tags script section to extract the Datto RMM Device ID from the local registry on the device and append it to any existing tags that might be configured. It might be best to have this configured optionally as a component variable as not everyone would want to use it, but it would be best to have this option enabled by default. Anyone who doesn't find it useful hasn't tried to reconcile the device lists in their various platforms yet. Here is the code that I'm using currently: $TagsKey = "__TAGS__" if ($env:HUNTRESS_TAGS) { $TagsKey = $env:HUNTRESS_TAGS } # # Below is my added portion $DRMMDeviceID=Get-ItemPropertyValue "HKLM:\SOFTWARE\CentraStage" -Name "DeviceID" if (([string]::IsNullOrWhiteSpace($TagsKey)) -or ($TagsKey -eq "__TAGS__")){ $TagsKey="DRMM:$DRMMDeviceID" } else{ $TagsKey=$TagsKey + ",DRMM:$DRMMDeviceID" } Since every endpoint agent added to the Huntress portal will have the Datto RMM DeviceID (unique value) added as a tag, it becomes possible to have a 1:1 correlation between the two platforms and have 100% accuracy in matching the devices between each portal.

There are instances where the Datto RMM site name may be different than the organization in Huntress. In these instances, instead of manually moving the endpoints in the Huntress portal, it would be better to have the ability to change the org name used by the deployment script. ------------------------------------------------------------------------- # Use the CS_PROFILE_NAME environment variable as the OrganizationKey # This should always be set by the DattoRMM agent. If not, there is likely # an issue with the agent. $OrganizationKey = $env:CS_PROFILE_NAME if (!$env:CS_PROFILE_NAME) { $OrganizationKey = 'MISSING_CS_PROFILE_NAME' } # # # If the site override variable is set, use this for the org name instead. if ($env:HUNTRESS_SITE_OVERRIDE) { LogMessage "Overriding site name." $OrganizationKey = $env:HUNTRESS_SITE_OVERRIDE } ---------------------------------------------------------------------------- The second section here is my addition to the script with the use of the $env:HUNTRESS_SITE_OVERRIDE variable. This section would allow the script to work as it exists currently if the value is not configured, but be modified to the value set as a site variable in Datto RMM if you need to make sure that endpoints in the RMM site are linked to a different Huntress Organization than the Datto RMM site name. This is needed for some organizations have multiple RMM sites or co-managed companies but are all technically the same. This is mainly for ITDR where multiple RMM sites would fall under the same company in 365. There are also occasions where a client may have an unique identifier in the RMM that should not be used elsewhere. The HUNTRESS_SITE_OVERRIDE value allows for configuring a sanitized value that should be used instead.

Please add more functionality to the external recon. like: Darkweb monitoring Domains and Subdomains Domain Doppelgänger Social Media Accounts Blacklist checks for Mailserver Shodan / IntellX We're doing all this monitoring with external Tools or manually at the moment

I am trying to build an internal tool separate from Huntress and need to access ITDR and SIEM data via the API. However, the current API documentation does not provide a way to retrieve this information on a per-company basis. It would be beneficial to have API access to ITDR and SIEM data to facilitate the development of internal tools.

Integrate with Syncro billing to update customer invoices with Huntress agent count.

The current API passes the site/org name to Halo. The current user field defaults to 'General User'. It would be nice to have the ability for the HaloPSA integration to also sync the identity/user and potentially the device name back to the ticket as well.