Feature Requests

We’d like to generate read-only API keys. Right now, all API keys have Super Admin–level permissions, which makes it unsafe to share with team members or third-party tools who only need viewing access.

Currently the MCP Server uses a single API key, meaning all actions are performed as the sysadmin account regardless of who the actual end user is. This creates both security and audit trail issues. Requested improvements: OAuth authentication – Allow end users to authenticate with their own Helpjuice credentials so actions are attributed to the correct user. Tool scopes/permissions – Add the ability to configure which tools are exposed to different users or integrations. For example, restrict access to sensitive operations like user management (Users ) and webhooks (Webhooks ) while allowing read-only article access. Why this matters: Proper audit trails showing who actually made changes Principle of least privilege – not every integration needs full admin access Enables safer deployment in multi-user environments (e.g., AI assistants with multiple end users) Possibility for custom tool clusters (eg. one MCP connection that only allows for searching the KB, another to only create new drafts, another that allows editing published articles and so on). This could revolutionize how we create, update and handle content in our KB.

We need to have HelpJuice easily accessible for our workflows. So instead of asking the questions 1 at a time, we want to have a public AI that will allow us to automate a connection to Swifty so we can just get the answers integrated on our tickets. My team would probably use it 3000++ times in a month

We are setting up our API user sync and have discovered that we are not able to bring over the data for "Job Title". It would be a huge improvement to allow organizations to bring over that field, as well as other additional fields into the user profile. As a next step, it would be amazing to be able to use that data to automate Groups.

Currently, we don't include the job title in the API response when retrieving users information. What is included "email", "name", "first_name", "last_name", "role_id", "created_at", "updated_at", "groups" etc. Consider adding this e.g. Trainer etc.

When we use API to retrieve an article, and the article is set to Private we don't see Groups or Users that are assigned to it.

When requesting an article via /api/v3/articles/:id with ?kb_language=, the API always falls back to the default language if the requested localization doesn’t exist. This makes it impossible to detect which localizations actually exist when consuming the API. Expected Behavior: API should provide the actual kb_language value(s) available for that article in the response body. This allows integrators to detect existing localizations instead of guessing. Proposed Fix: Include kb_language in the article object returned by /api/v3/articles/:id. Ensure webhook payloads also include kb_language info when firing.

Currently, we can't filter API v3 article results by archived. It would be useful if we could add an archived filter to the API V3 endpoint for articles. We also don't have the archived information in API v2 when retrieving the information in JSON and .xls formats. We should add it to these formats too.

Your current rate limits make it difficult to build integrations. Please raise them.

It would be great if there was a possibility to export all Article keywords