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).
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.
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.
Option to render emojis as native characters in the editor
In the new Notion-style editor, emojis are rendered as image files from an external emoji set instead of as native Unicode characters. Emojis typed or inserted into an article are converted to images, and users can’t turn this off. This is a change from the previous editor, and some users find the image-based emojis look lower quality than the native emojis they’re used to. We’d like emojis to render as native Unicode characters, either as the default or through an account-level or user-level setting. Existing articles that already contain image-based emojis would ideally display natively as well under that option.
KBs resizing inline graphic
We used to be able to resize an image right in the KB editor. What happened? Ability to resize and crop in editor is basically a necessity. Can we get this back?