Integrations, Webhooks, APIs

JumpCloud's AI Gateway needs a refresh token from OAuth in order to work. At the moment Huntress' MCP server doesn't supply one. To the degree reasonably possible centrally managing, securing, and logging access - whether by humans or agents is important to us. I'll apologize up front for the short Claude copy/paste below, at least it's short and to the point. Huntress’s public OAuth settings ( https://api.huntress.io/.well-known/oauth-authorization-server ) list the grant types it supports: "grant_types_supported": ["authorization_code", "client_credentials"] Refresh_token isn’t in that list, so no Huntress sign-in will ever produce a refresh token, however many times you reconnect. The gateway’s error says it needs one: “… no refresh token stored”. It treats that as fatal instead of using the access token it already holds. So JumpCloud’s Huntress connection is built in a way that can’t work with Huntress.

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 .

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

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.

Today an API key is created at the account user level and inherits that user’s visibility across every organization in the account. There is no way to issue a key that can only see a subset of orgs. As an MSP we want to expose Huntress data to internal tooling (MCP server, scripts, dashboards) with different trust levels. Two examples- A key for our technicians that can query all client organizations but not our own internal Protek org. Compliance-driven scoping, for example a key used by out-of-country staff that is limited to the orgs they are cleared for, or a client-specific key for a regulated tenant (CMMC / ITAR) that cannot read other clients’ data. The workaround is a dedicated user account per scope, which is clumsy to manage and still exposes everything that user can see. Ask: let an account admin set an org allowlist (or denylist) on an API key at creation time, independent of the creating user’s own access.

You have everything BUT the option to select what Status in the ticket. Right now it just uses the default for that board but would like to select a status that I want.

Currently the Halo integration can create tickets/alerts but we cannot respond or close from Halo, Can this be expanded to a 2-way communication so our agents can work / close items in Halo instead of needing to close the Halo ticket and the huntress ticket separately.

Would like to see some sort of integration into Jira. Jira is a widely used service management tool and being able to route incidents, events, etc into Jira would be helpful for tracking purposes, esclations, etc. This is something that S1 can do today but their implementation is wonky.

Hello, Syncro allows integrations where an Iframe displays on the main dashboard so that you can work inside of the PSA. Could we something like that made so that we can log into Huntress but within Syncro? I am attaching a screenshot of what I mean about the Iframe. This is the dashboard of PAX8, a distributor within Syncro's PSA. Thank you for your help in advance.

Great to have this integration built. We have one request. Can Huntress add the mapping of priorities? We would like to match the Huntress "Critical, High and Low" with ticket priorities in HaloPSA. This would help flag critical and high events more quickly. Thanks!