Integrations, Webhooks, APIs

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.

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.

There is a learners:manage scope, but not really a way to take advantage of it. We would like to be able to sent a post request (after authentication of course) to add leaners and ideally be able to update learners' information as well.

Ability to retrieve, through an API endpoint, a list of all defender exclusions/details.

t would be extremely valuable if the ConnectWise Manage integration included the affected user in the ticket details when creating Huntress ITDR alerts. Many MSPs provide their clients with visibility into their ConnectWise Manage tickets. While the current integration includes the alert details, the ticket often lacks the key piece of information the client is looking for—which user triggered the ITDR event. Including the affected user (for example, UPN, display name, or email address) in the ticket description or summary would provide several benefits: Reduce the need for technicians to manually update tickets with user information. Improve the customer experience by providing immediate context. Allow service desk teams to identify the impacted user without opening the Huntress portal. Reduce unnecessary back-and-forth between customers and technicians. Improve reporting and automation workflows that rely on ConnectWise Manage ticket data. This information is already available within the Huntress ITDR alert, so surfacing it through the ConnectWise Manage integration would make the integration significantly more useful and provide greater value to MSPs managing customer-facing ticket queues. This feels like a natural enhancement that would improve both operational efficiency and the customer experience.

We are unable to use the current CloudFormation template for AWS GovCloud as it is not supported. It would be beneficial to have a GovCloud-specific template to enable integration in these regions, especially for compliance and operational needs.

Hi - can we get Atera integration up to par by auto ticketing on events to correct customer. Also make deployment easy in the script by auto generating the companies in Huntress and deploying to said company.

Please make the NinjaOne connection more like the SentinelOne connection. While connecting NinjaOne to the SIEM, we were not able to split the data coming in by the Organization as built in NinjaOne. The events being ingested by the SIEM show the NinjaOne Organization, but all of the data can only be sent to a single Huntress Organization. SentinelOne allows for a single API key to be created. This only has to be connected one time in Huntress, then any organization current or future, will show as an Unmapped Organization. This capability is not available for NinjaOne, but it needs to be! Please.

As a top-tier Huntress MSP partner securing thousands of endpoints, we’ve built our practice around Huntress’s elite MDR, EDR, Managed ITDR, and 24/7 SOC remediation. Email is still our biggest blind spot. Phishing, BEC, ATO, credential theft, malicious rules, deepfakes, and QR lures dominate our breaches. Microsoft 365 Defender catches basics—but consistently misses polymorphic, low-and-slow, and socially adaptive threats.We’ve deployed IRONSCALES widely with outstanding results thanks to its Adaptive AI email security: Native M365/Google Workspace API—no MX changes, instant behavioral learning Real-time user/tenant baselines, social graphs, reputation, content analysis + 30,000+ hunter intel One-click auto-remediation: quarantine, rule delete, session kill, polymorphic clustering Hybrid AI + human triage → minimal FPs, strong zero-day BEC/ATO catch rate Built-in AI spear-phishing sims + in-client banners/report buttons Without integration, we’re stuck in silos: separate dashboards, manual correlation, duplicated triage, delayed chain-attack visibility (phish → credential → endpoint). This inflates MTTR and MSP overhead. A tight Huntress + IRONSCALES integration delivers... Technical wins: Unified timeline: IRONSCALES email signals + Huntress ITDR/endpoint data for true multi-vector detection SOC efficiency: enriched alerts routed to Huntress portal for 24/7 contextual triage/remediation Automation synergy: Huntress Microsoft depth + IRONSCALES mailbox APIs → enrichment, noise cut, proactive blocks Cross-domain hunting: email + endpoint + identity queries for faster forensics GTM wins: Killer layered stack (endpoint + identity + email) that crushes fragmented or native-Microsoft-only competitors Easy cross-sell/upsell → higher ACV, faster closes, stickier renewals Lower support load & churn with single-pane visibility + managed response RFP dominance by owning the full modern attack surface IRONSCALES already integrates cleanly elsewhere (e.g., ThreatDown unified console)—proof it works. Huntress has the engineering and MSP DNA to nail this fast. Product team: this is mission-critical. Close the email gap, stop breaches earlier, supercharge partner revenue.