Integrations, Webhooks, APIs

It would be good to have some sort of access to Post API commands to Huntress so we can dismiss Alerts from our PSA tool, rather than having to log into Huntress. Also the ability to create rule to bypass detections for Countries.

Would love to see the ability to close a PSA ticket, and in turn, that resolves the incident.

It would be huge if we could get Huntress to link up with BrightGauge for report consolidation

Ability to create email integrations at the organization level so incident reports for certain organizations will be sent to them and not the account level emails.

Rewst is a common tool used in MSP's and supported webhook authentication by providing a secret value published under the "x-rewst-secret" key, which is supported by CIPP and other tools to authenticate webhooks. Rewst does not yet support Svix signatures, but this would be a good addition in the meantime to secure webhook endpoints using Rewst's native functions. See https://docs.rewst.help/documentation/automations/intro-to-triggers/use-cases-and-examples/using-webhook-triggers#set-trigger-parameters .

For MSPs and larger organisations, it is common for individual organisations to need to integrate their security tooling with third-party platforms such as Rapid7, Microsoft Sentinel, Splunk, or other SIEM solutions. Restricting webhook configuration to Account Admins only creates an unnecessary operational bottleneck and limits customer autonomy. Ideally, Account Admins should be able to delegate webhook management at the organisation level, or alternatively enable organisation-specific webhook integrations that are scoped only to that organisation's data. This capability is becoming increasingly important as customers seek to consolidate security events into central monitoring and compliance platforms. The inability for organisation administrators to manage their own integrations is likely to be viewed as a platform limitation when compared to competing security products. I will submit the feature request through the feedback portal, but I wanted to provide this additional context as the requirement has arisen from a real customer deployment integrating Huntress with Rapid7 InsightIDR. Thank you for taking the feedback on board. Kind regards, Marc Hauswirth

I wanted to share product feedback based on what I am seeing with SMB and mid-market clients. Huntress already covers a major part of the risk stack with EDR, ITDR, SAT, SIEM, and now ESPM/ISPM. The gap I see is the browser. A growing amount of compromise is happening before traditional endpoint tools get a clean signal. The main use cases are: ClickFix-style attacks where users are tricked into copying and running malicious commands from fake CAPTCHA, fake Cloudflare, fake browser update, or fake document pages. Malicious browser extensions that collect credentials, hijack sessions, inject scripts, exfiltrate data, or abuse permissions after being installed by the user. SaaS and identity abuse where users approve rogue OAuth apps, reuse passwords, enter corporate credentials into unmanaged apps, or upload sensitive data into shadow SaaS and AI tools. This feels like a natural Huntress expansion because these attacks sit between endpoint, identity, and SaaS. Today, the practical answer is to use Intune/GPO/Chrome Enterprise/Edge policies for extension governance and a separate browser-native tool such as Push Security for in-browser user protection. That creates another tool, another agent/extension, and another dashboard for MSPs. The ideal Huntress capability would be a lightweight managed browser extension or browser-security module that can: Detect ClickFix behavior, including malicious copy/paste instructions, fake verification flows, and suspicious browser-to-command execution paths. Inventory Chrome and Edge extensions across managed endpoints. Score extensions by risk based on permissions, publisher reputation, install source, update behavior, and known malicious indicators. Alert on risky extensions, new high-permission extensions, sideloaded extensions, and suspicious extension changes. Help enforce extension allowlists or integrate with Intune/Chrome/Edge policy management. Detect corporate password reuse or credential entry into unapproved sites. Detect risky OAuth grants and connect that back to Huntress ITDR. Warn users in-browser before they enter credentials, approve OAuth access, copy malicious commands, or upload sensitive data into risky SaaS/AI tools. Give MSPs simple client-facing reporting: risky extensions, risky SaaS usage, browser-driven phishing exposure, and user behavior trends. The business reason is simple: attackers are moving into the browser because it is where identity, SaaS, credentials, AI tools, and user decision-making all meet. Huntress already has strong coverage after compromise. A browser-native protection layer would help move Huntress closer to prevention without losing the managed detection value that makes the platform useful for SMBs. My ask: please consider adding browser extension governance and ClickFix/browser-native protection to the roadmap, either as part of ITDR, ESPM, ISPM, or as a dedicated managed browser security module. This would be highly valuable for MSPs and small security teams that want Push Security-like browser protection without adding another standalone platform.

I would like the ability to report unresponsive agents to the Integrated PSA, specifically using Syncro. Currently, the system only notifies admins when unresponsive agents are uninstalled, but not when they become unresponsive. Implementing this feature would help in monitoring and managing agent responsiveness more effectively.

We have realized that one of our ITDR integrations was marked as "unhealthy" and needed to be re-synced, but it did not generate a ticket to our PSA. I do not see a way to configure alerts for this, and it would be helpful to be able to have alerts for this sent to our PSA so we can fix it before incidents are missed.

We are building automation to keep SAT training assignments in sync with employee lifecycle changes (joiners, movers, leavers) using our Google Workspace IdP as the source of truth. Currently the API does not expose the controls we need to make this fully automated, requiring manual UI or CSV intervention. What we need (at least one option): Learner tag management via API The ability to create, assign, and remove tags from learners programmatically. Tags appear to be the intended mechanism for cross-group segmentation, but they are not exposed as documented API operations today. Assignment audience extras via API Expose the Assignment > Audience > Enrollment > Extras > Include learner workflow as an API endpoint. This would allow us to add or remove individual learners from an assignment's audience directly, as an alternative to tag-based targeting. Use case / motivation: When an employee joins a team or changes role, we want to automatically enroll them in the relevant security training and remove them when they leave or change. (The only option today is the value of the Department mapping or all Organization, that is not granular enough to give additional training across departments but not everyone). Our IdP already manages group membership - we just need the API to reflect those changes in SAT assignments without manual steps. Current workaround: Manual UI updates with the (Assignment > Audience > Enrollment > Extras > Include learner workflow), which do not scale and introduce lag and human error between changes Reference: Huntress support ticket 247087