Feature Requests

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.

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

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

User Story As a Content Localization Manager I want to link translated versions of articles via the Helpjuice API (v3) So that I can programmatically associate translated content without manual entry in the Helpjuice UI ("Link an existing translation" functionality) Business Value: Streamline multilingual kb management and ensure content consistency across languages. Acceptance Criteria: Endpoint Exposure An endpoint is available that allows us to link an article (does this need a language_code?) Edge cases Should be able to manage existing translations as well. I'm assuming that if I delete a linked / translated article that the current link will be removed. This functionality should be exposed here as well.

At the moment, retrieving users via API v3 doesn't include a field for active/deactivated users, so it's not possible to differentiate/identify users that are deactivated.

Using the search function via API only references titles and keywords. This severely hinders the search result relevance and requires archaic keyword addition logic by article creators. Having the Swifty Chatbot functionality would allow searching of indexed article content

Customers would like to use API v3 to upload images directly to the Files Manager.