Please check existing posts to see if your feature request already exists.
🐛 If you’ve encountered a bug, please submit a ticket to the Hudu support team to ensure a quick response.
Have a feature idea or feedback on how we can improve Hudu?
Enable one-click SSO sign in
The new log in removed the single click to sign in, and users must now enter their email each time to log in to the instance. Please offer an option to return the one click SSO sign in.
Huntress Integration Identity Matching
The new Huntress integration create identity objects using the email address rather than attempting to match an existing object that contains the email address. Since we migrated from IT Glue our roughly 20k identities are created using the actual name of the user. Different matching options would make this more usable.
Huntress Integration Agent Sync
The new Huntress integration allows syncing of agents, but it assumes all agents will the same asset type in Hudu. We currently distinguish between user endpoint and servers. Is it possible to allow more elaborate mapping?
Clearer change highlighting in Compare Differences
When comparing article versions, unchanged text in a changed line is shown on a light green background, and the actual edit is a slightly darker green. Those two greens are too similar, so the real change is hard to spot. Please highlight only the added/removed text in green/red, and leave the surrounding unchanged content uncolored (or with a much clearer contrast).
Option to hide unchecked checkboxes on an asset
Checkbox fields always show on an asset, even when they are not checked. On assets with many checkboxes, such as device roles or printer features, most of the page is taken up by items that do not apply. We would like an option on checkbox fields, or on the asset layout, to hide a checkbox when it is not checked, or to show only the checked items. This would make assets quicker to scan and would help teams that track lots of yes or no attributes.
Restrict API keys with password access to specific password folders (so a breached integration can’t expose every password).
Hi Hudu team, Integrations like CyberQP QuickPass password rotation tools need API access to read and update passwords in Hudu. Today, once an API key is given the “view passwords” permission, it gets full access to all passwords, including viewing, editing, and deleting. A key can be limited to a company, but not beyond that. If an integration vendor is breached, an attacker could reach every password in the scope of that key. Why now: Last week’s compromise of ConnectWise’s cloud backup gave attackers access to the Microsoft tenants connected to it. It made us look at every vendor with access to our data, and a vendor with broad password access in Hudu is one of our biggest exposures. Request: add a folder limit to API keys, the same way we can limit them to a company today. An admin could restrict a key to: A folder belonging to one specific company, or A global folder, giving the key access to that folder across all companies The key would only be able to access passwords inside the folders it’s been granted. Also requested: let admins edit existing API keys, including permissions, company and folder limits, and IP restrictions. Today, tightening a key (such as adding an IP restriction or updating an IP) means deleting it and creating a new one, which also means reconfiguring the integration. Also helpful: separate view, create, edit, and delete permissions for each availble asset, including passwords only with no asset access instead of one “view passwords” toggle that grants everything. This would let MSPs use password automation without making every vendor a single point of failure. Thank you!
Deleted Items - Recycle Bin Feature
Currently, when an item is permanently deleted, there is no option to restore it directly from the UI. The recommended recovery process is to restore a backup to a separate instance and manually recreate or copy the required data. I completely understand the reasoning behind this approach, but I wonder if a simpler option could exist for day-to-day operational mistakes. Would it make sense to introduce a Deleted Items / Recycle Bin feature? For example: Deleted items would be retained for 30 days (or a configurable period). Admins could review and restore deleted records from the UI. After the retention period, items would be permanently removed. Activity logs and deletion details would remain available. In my experience, accidental deletions are much more likely than full disaster recovery scenarios. Having a safety net for restoring a single asset, password, article, website, or company record could save a lot of time and reduce the need to work with backup restores for relatively small incidents.
Portal Access Concerns
I have some concerns with the User Portal changes in v2.47, specifically around password visibility and permissions. First, passwords stored in a client's root folder appear to be accessible to portal users by default. From a security standpoint, I'd prefer a default-deny approach that follows the principle of least privilege. Access should be explicitly granted rather than requiring administrators to take additional steps to restrict it. This is particularly concerning for existing passwords that may have been created without any expectation of being accessible through the User Portal. We shouldn't have to reorganize credentials into subfolders or modify individual records simply to maintain their existing level of access. Second, relying primarily on folder-based permissions creates unnecessary complexity. For example, if John needs access to Password 1 and Password 2, but Janet only needs Password 2, we now have to create separate folders to accommodate those permissions. Since a password can only reside in one folder, this also forces us to organize credentials around access requirements rather than their logical purpose. I understand the goal was to move away from the previous portal's permission model, and I can appreciate the benefits of folder-based permissions for managing access in bulk. However, I think there should still be an option to restrict access by default and grant permissions at the individual password level. Ultimately, I'd like to see folder-based permissions and individual record sharing coexist. That would provide flexibility without compromising least privilege or creating unnecessary administrative overhead.
Sync multiple IP and MAC addresses from NinjaOne
Devices in NinjaOne often have more than one network adapter, each with its own IP and MAC address. The NinjaOne connected field for IP address only brings in one address, and there is no way to choose which one or to bring in more than one. We would like to be able to sync every IP and MAC address on a device, or at least choose which adapter each connected field uses. This would make network documentation more accurate and would save teams from filling these in by hand or with their own scripts.
Map several NinjaOne checkboxes into one Hudu list field
Many teams use NinjaOne checkboxes to track things like server roles (file server, DNS, print server and so on). Today each NinjaOne field can only be connected to a single text or rich text field in Hudu. To show these as one tidy list on an asset, you have to build your own script. We would like to select several NinjaOne checkbox fields and have Hudu combine the ones set to yes into a single field on the asset, such as a list. For example, an asset would show “File server, DNS, Print server” instead of a separate checkbox for every role. This keeps asset pages shorter and easier to read, and it saves teams from maintaining their own sync scripts.
Reveal password before accepting/rejecting
When requesting a password via link, it would be nice if we could reveal the password before accepting or rejecting the write to the password in Hudu. Currently, you have to go to the revision history and copy the old password to roll it back if the provided password doesn’t meet criteria, which can only be viewed after accepting the change.
Configurable sync interval and scheduling for integrations
Native integrations currently re-sync on a fixed platform-wide interval (roughly every 3-4 hours), and admins have no control over how often or when that happens; the only option for fresher data is a manual re-sync. We'd like admins to be able to set the sync interval per integration and/or schedule syncs for specific times of day. Customers who rely on near-current data, such as RMM device inventory, end up re-syncing manually to fill the gap, while others may prefer syncs to run at predictable times, like outside business hours.
Allow the mobile app to act as a passkey authenticator
Allow the Hudu mobile app to act as a passkey provider for cross-device authentication, so that passkeys stored in Hudu can be used on devices without the Hudu extension.
Support connecting Hudu MCP directly to Microsoft 365 Copilot agents
Microsoft 365 Copilot agents built with the Microsoft 365 Agents Toolkit can’t currently connect to Hudu’s MCP server. During setup, Microsoft requires the server to issue a client secret when the agent registers, and Hudu doesn’t. Please add support for this so Hudu MCP can be used directly in Microsoft 365 Copilot, without Copilot Studio.
Unifi OS add VLAN to IPAM
today you are pulling in all the networks to IPAM through the integration but not adding the VLAN to it. Might be related to this UniFi network config add vlan to networks IPAM overview - Hudu but thats for the old integration i believe. Also a side note, saw that “UDM Pro Max” was tagged as a “switching” but that might be UI API issue, so it got added to the switches instead of gateways.
NinjaOne integration: sync SNMP inventory (firmware and Custom SNMP attributes) for NMS devices
Proposed solution Pull SNMP-derived inventory for NMS devices from NinjaOne, including manufacturer, model, serial number, and firmware, when they aren’t available under system. Add a firmware Connected Field for NinjaOne devices. Allow Custom SNMP monitoring attributes (custom OIDs) to be mapped to Hudu asset layout fields, similar to how NinjaOne Custom Fields can be mapped today. Show these values on the NinjaOne card for NMS devices.
Semantic search using Claude
Currently OpenAI is the only option for Sematic search but we use Claude. Please add Claude as an option to enable sematic search.
MCP/API | KB modification without full re-write
We are working heavily with the MCP connection to our KB documents and leveraging Claude to help write the documents and move them over from our previousl system. However, we have found that every modification requires a full re-write of the KB article. This burns through a massive amount of tokens. It would be nice if we could do a modification without a full re-write. Not sure where the limitation lives for this.
MCP server: add a tool to upload images for use in articles and assets
Problem The MCP server can create and edit KB articles, but it cannot upload images. External AI clients such as Claude and ChatGPT don’t pass chat attachments to MCP servers, so the attachment:// references in the article tools only work in Hudini. The documentation also lists uploading public photos as not supported. As a result, an AI client can write a complete how-to article but can’t add the screenshots. For end-user documentation the screenshots are the most important part, so every article still needs manual work in the editor. Proposed solution Add a tool such as public_photo_create_tool that accepts an image (base64 or multipart) plus an optional record type and ID, and returns the /public_photo/ path. The article and asset tools already accept those paths, so no other changes are needed. Why this is a small change The building blocks already exist. Hudini can embed attached images, and article content with inline image data is already converted to public photos on save. Exposing that as a dedicated tool would make it reliable for every MCP client. Use case As an MSP, we create generic, client-facing KB articles with screenshots. With this tool, the full article including images could be created from an AI client in one step.
Track SPF/DMARC/DKIM activity in website version history
Currently, changes to SPF, DMARC, and DKIM records are not captured in the version history for websites. Reasoning: some third parties manage domains for our customers, and mistakes sometimes happen during record transfers, resulting in records being deleted. Having the ability to see past records when changes occur would help identify what was lost or changed and when.