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?
In Progress
Option to exclude API from IP allow list enforcement
Prior to 2.45.0, IP allow list controls didn't apply to the API. As of 2.45.0, they do, requiring customers to whitelist every IP their API integrations (CIPP, Halo, ScalePad, etc.) call from. Request: add a setting to exclude the API from IP allow list enforcement, so customers can opt back into the pre-2.45.0 behavior if they don't want IP restrictions applied to API traffic.
API support for password requests
It would be great to have the new password requests available through Hudu’s API, so they can be created programmatically instead of only through the web app. Use-case example: a PSA integration could let agents click a button while replying to a ticket, fill in the required details, and have the integration create the password request in Hudu and add the resulting link to the reply.
Filter and return labels on GET /articles
Add API support for filtering articles by label, and include each article’s labels in the response.
Company group scoping for API keys
API keys currently support only two scopes: global (all companies) or a single company. There's no middle ground for a customer who wants a key limited to a subset of companies. Request Add a third scope option for API keys: company group. This would let an admin select a defined group of companies (rather than one company or all companies) that the key has access to. Use case An MSP with multiple internal teams or business units wants to issue API keys scoped to a specific set of clients, without granting access to their entire company list or having to manage a separate key per company.
Granular API key permissions for password and OTP visibility
API keys currently only offer a single "view passwords" permission, which also grants access to OTPs. There's no way to grant access to one without the other. Request Split this into two separate permissions on API keys: View passwords – grants access to stored passwords only View OTPs – grants access to OTP codes only This lets admins scope API keys more tightly, for example, issuing a key that can pull passwords for an integration without also exposing OTPS.
Scoped Company API cannot access Relations for Assets in the Company
I have a scoped API key for a company (e.g. 152) that allows me to query all assets for that company. How can I retrieve all relations for that asset (e.g. 867) that belongs to that company? My API key does not have permission to retrieve these relations - receiving a 401 unauthorized {"error":"Permissions scoped to company"} echo "== Confirm asset 867 belongs to the allowed company (152) ==" curl -s "https://mycompany.huducloud.com/api/v1/companies/152/assets?page=1&pagesize=1000" -H "x-api-key: $HuduApiKey" | grep -o '"id":867,"companyid":[0-9]*' echo echo "== Now query /relations filtered to that exact asset, same scoped key ==" curl -s -i "https://mycompany.huducloud.com/api/v1/relations?fromabletype=Asset&fromableid=867" -H "x-api-key: $Hudu__ApiKey" | head -20
Show IP address on API-generated activity log entries
Problem: Activity log entries created via the API don't include the IP address the request came from. The web UI shows the IP address for browser-based actions, but API actions don't carry it in the response. Why it matters: Admins can't tell where an API action originated from, which limits security auditing and troubleshooting for API key misuse or unexpected automation behavior.
Asset Layout retrieval should be allowed for Company-Scoped API key
Currently, asset layout cannot be retrieved with a company-scope limited API key. Company-scoped API keys should be allowed to retrieve asset layouts to support scripting to add assets of that type to the company and similar uses. Nearly all of the information in Asset Layout is otherwise available to a Company-Scoped API key by just retrieving an asset of that type, so there seems little increased risk.
KB Article Images Management | Orphaned Images
Currently, "POST /publicphotos" creates images embedded in KB articles, but there's no way to remove a '/publicphotos' image. The API exposes only GET and PUT, and public photos look to be excluded from the Photos module ("Upcoming Feature" per the API docs), so they have no UI surface either. Once created, a public photo cannot be removed by any supported means. As far as I am aware, Hudu never reconciles attached photos against article content. Remove an image from an article body within the editor or via the API and the photo stays attached to the article forever. I tested deleting article versions, and Hudu doesn't reap them. Digging into this issue further, I found that one of our articles carries 25 attached photos to render 4. Any instance where either a user edit articles or an article is edited via API, accumulates photos silently. This becomes acute for API-driven documentation sync. I'm working on an automation that pushes article updates into Hudu; each run re-uploads the article's images, and every previous set is orphaned permanently with no cleanup path. I am working around it by tracking image identity externally and skipping re-uploads, but that doesn't fully mitigate the underlying issue. Can we get a "DELETE /api/v1/public_photos/:id" API call, gated behind the existing destructive-actions key permission? Alternatively, having Hudu self purge images not assigned to a KB article or a version of an article would be useful; or both for those of us who want to automate this ourselves, and keeping good data hygiene for those that do not.
'Processes' and 'Task' Improvements to current API Endpoints
I have created an on-prem 'New Starter' process and we were looking at using Processes to track script progress and any uncompleted sections of the automation process. I created a 'Process Template' within Hudu and began digging into the API Documentation to see how best to achieve this. After seeing that you've got endpoints to create a new process from a template, and the ability to kick off a run of the new process - Perfect! The issue arose when investigating how to mark Tasks complete (the backbone of the process I had planned), and noticed there's a very weird Note at the bottom of the PUT request. Note: Completion fields (completed, completedat, userid, completion_notes) are silently ignored if sent—use the application UI to mark tasks complete. This seems so counter-intuitive! I presume this was disabled for a reason, and I'd love to know it. If enabling 'Completion fields' is too much of a hassle, please could you add a new PUT endpoint for 'Complete Task', where we can pass the Process ID and Task ID to complete the task. Thank you for reading my request
API endpoint for all related-items panel items
This should allow a user with an API key to run GET, DELETE, PUT, and POST requests to add or remove any items on the side panel, such as comments, relations, etc.
API to get all records in folder
Now there's no API to see which records (articles) are in the article folder. You need to loop over all articles to then have your list of articles in a specific folder. Like a: "Get all records in folder by folder ID" or so… Would be great if there would be a parameter to "include records in subfolders"!
API GET on records include label_id's
When using the API to get an article for example it would be great to see which labels it has applied. This way labels could be used to automate flows for articles or assets.
Ability to get archived companies
Currently, archived companies aren't retrievable from api that makes them the only object type that once archived, is no longer accessible. this occasionally causes complications with unique company name being enforced. This is because we can't see archived company names that we could be colliding with when renaming or creating other companies.
API keys for specific users
Now API keys are generic, and when adding or modifying assets it results in HuduBot as the user who performed the task. Would be really helpful to track a real user which performs activities via APIs. Please add the possibility to create API keys related to specific Hudu users, so that we get the real user when he does any modification via APIs.
Add API Endpoint to Trigger Website Asset Refresh
It would be great to have a dedicated API endpoint to programmatically trigger a refresh of website assets in Hudu, similar to the "Refresh" button available in the web GUI. Use Case: Being able to trigger a refresh of all monitored website assets on a schedule (e.g., nightly) would allow us to ensure all expirations (like domain registration) are up to date for the alert emails. Currently, there's no way to trigger a refresh via the API - users must manually click "Refresh" on each website in the GUI, which doesn't scale. Proposed Solution: Add a new endpoint to the Hudu API: Option 1 (by ID): POST /api/v1/websites/{id}/refresh Option 2 (by slug): POST /api/v1/websites/{slug}/refresh Option 3 (bulk refresh): POST /api/v1/websites/refresh_all Response format: 200 OK (or 202 Accepted for async queueing) Why This Matters: Enables automation of website monitoring workflowsMatches functionality available in the web GUI (/websites/{slug}/refresh)Particularly useful for MSPs managing multiple client sites who need scheduled refreshes Current Workaround (insufficient): Using the existing PUT endpoint /websites/{id} only updates metadata - it doesn't trigger a fresh scan of the websiteThe GUI refresh endpoint exists but requires GUI session auth and isn't accessible via the documented REST API References: GUI refresh URL pattern: https://[instance]/websites/[slug]/refreshCurrent Website API endpoints: GET/POST/PUT/DELETE /websites and /websites/{id}Existing refreshed_at field in Website model (read-only) confirms refresh functionality exists internally
Field-level Data anonymization for API and MCP responses (asset fields + KB articles)
Summary: Add the ability to mark data as "anonymized" so that the real value is replaced with a configurable placeholder whenever the content is retrieved via the API or the Hudu MCP server, while the actual value remains visible in the Hudu web UI as normal. This should work in two places: as a per-field setting in Asset Layouts, and as an inline syntax in Knowledge Base articles. Part 1; Asset Layouts: In the Asset Layout editor, each field gets a new boolean setting, e.g. "Anonymize via API/MCP". When enabled, an "Anonymized value" template can be defined per field, for example: Real value: "Anders Andersson" → API/MCP returns: "[firstname lastname]" Real value: "anders.andersson@company.se" → API/MCP returns: "[email]" The placeholder text is fully configurable per field in the layout. Part 2; Knowledge Base articles: KB articles are free text, so a per-field toggle doesn't work there. Instead, support an inline markup syntax that pairs the real value with its placeholder, for example: ((Anders Andersson)[firstname + lastname]) Behavior: In the Hudu web UI, the article renders the real value: "Anders Andersson" Via API/MCP, the article body returns the placeholder instead: "[firstname + lastname]" This lets us write articles naturally (e.g. "Contact ((Anders Andersson)[firstname + lastname]) at ((070-123 45 67)[phone]) for access requests") while keeping personal data out of API/MCP responses. The exact syntax is open for discussion — the key is one expression containing both the displayed value and the masked replacement. API Keys are toggled with data anonymization: true/false Optional enhancements: A scope setting (anonymize for MCP only, API only, or both), since AI/MCP use cases often have stricter requirements than internal API integrations. A permission or API-key-level flag to allow specific trusted integrations to receive unmasked data. Why this matters: AI/MCP integrations: With the Hudu MCP server, asset and article data can now be passed to LLMs. We want to use this for troubleshooting and automation without exposing personal data (names, emails, phone numbers) to AI models. GDPR compliance: As an MSP operating in the EU, we must apply data minimization. Would be HUGE for our AI-journey. Maps in to AIUC-1 Controls - Domain A Expected outcome: We can flag sensitive data once — per field in layouts, or inline in KB articles — and every API/MCP consumer automatically receives masked values, while technicians working in the Hudu UI still see the real data they need.
Read-Only API keys
It would be great to have more granular control over API key permissions, especially the ability to create read-only access keys.
Add Process Run tasks to API
Give the API the ability to do things like start Process Runs, check off tasks, etc. This way we can utilize automation platforms (like Rewst) to assist in (or fully complete) documented process runs.
API - Make Uploads Relateable (for reuse and one-to-many)
Currently, we cant relate a single file to many objects because Upload model class can't be added to a new relation. Between this and having one uploadabletype and only one uploadableid, when relating a single file to multiple objects, it necessitates multiple uploads (of the same file) if we have one file (say an installation zip) we could relate that to all our user assets at once without duped files current relateable types are: Article, Asset, AssetPassword, Company, IpAddress, Network, Photo, PublicPhoto, Procedure, RackStorage, Vlan, VlanZone, so we do have this functionality for images