Feature Request

Currently, there is no way to track the usage of API tokens, including how frequently they are used and which API endpoints they interact with. Customers have expressed the need for visibility into their API token usage for security, compliance, and monitoring purposes.

We’re currently reorganizing our knowledge base and are trying to replicate a set of articles from our General space into other spaces and specific folder structures. We’ve attempted to handle this programmatically via the v2 REST API, but we’ve run into a blocker: articles marked as is_shared_article: true appear to be completely immutable via the API (e.g., cannot be forked, updated, or moved). Since replication seems to create these “shared” instances, this prevents us from automating the process at scale. This impacts ~4000 articles. Our goal is to replicate these articles into new locations while preserving their shared/linked behavior, not creating independent copies. We'd love to see some form of bulk replication supported in a future update. Thank you.

Ability to filter articles returned from the Project Version Articles API endpoint based on reader group ID. This would ensure that only content permitted for a specific reader group is fetched and displayed in external applications such as chatbots. The current multi-step workaround using separate endpoints is complex and not optimal for their use case. Adding a reader group parameter directly to the endpoint would provide a cleaner and more efficient solution. This enhancement is especially important for scenarios involving multiple reader groups with dynamic content access control. https://apidocs.document360.com/apidocs/project-version-articles

Currently there are no API endpoints to access analytics, which is vital functionality to extend reporting functionality and integrate it the insights into other tools.

The customer is using the GET API to retrieve Document360 article content and display it in their external application. They are capturing user feedback (likes, dislikes, and comments) within their application and require a way to sync this feedback back to the corresponding Document360 articles. They are requesting a new API endpoint or enhancement to allow ingestion of feedback data into Document360 analytics for centralized reporting and feedback management.

Integrate Document360 into Microsoft Copilot Knowledge for content requiring authentication. https://learn.microsoft.com/en-us/microsoft-copilot-studio/knowledge-copilot-studio

Currently, the API returns a hidden attribute when retrieving the settings for categories or articles which is based on the hidden status of the particular category/article. However, sometimes you just hide a category on a higher level and rely that all children inherit that setting implicitly and are hidden automatically. We would like to somehow get an "effective" hidden status via the API that reflects if an article is generally hidden on the site, either because it is set hidden directly or because one of its direct parent categories is set to hidden.

Request to enhance the API to fetch the status of an article using the Article ID, including states like deleted, unpublished, hidden, and in review. Currently, only draft and published statuses are supported, and deleted/unpublished articles are not returned in the API response. This makes it difficult to track content changes and maintain synchronization with external systems. Adding this capability will improve visibility into the article lifecycle and API usability.

This request is created on behalf of Udo At this time, the tags aren't included when retrieving article content. It would be great if we tags are also included in the same response. Thanks.

Currently, tags and metadata are not returned in the Get Article endpoint, requiring an additional API call to fetch article settings. This increases complexity and impacts performance for API-based implementations. Including metadata in the same response would simplify integrations and reduce API calls. It would also help in use cases like country-based content filtering on external portals.