Feature Request

When a write operation is called with an invalid or stale user_id, some endpoints return a generic error that does not identify user_id as the cause. Users running automated pipelines cannot distinguish a user_id validation failure from other operation errors, which makes the root cause difficult to identify without manual investigation. Workaround Limitations: Users must rule out all other possible causes (endpoint path, token permissions, payload structure) before identifying an invalid user_id as the root cause. No actionable information in the error response points to user_id as the field to check. Requested Solution: All endpoints that accept user_id as a required field should return a specific 400 validation error when the provided user_id does not exist in the project. Specifically: Return a description that identifies user_id as the invalid field (for example: "The user with id 'xyz' does not exist in your project."). Apply this validation response consistently across all write endpoints that accept user_id, not only the fork endpoint. Benefits: Reduces time to identify the root cause of failed write operations in automated pipelines. Improves consistency of error messaging across the API surface. Use Cases: CI/CD pipelines automating content updates, integrations passing user IDs from external identity systems, teams maintaining long-running automation where team membership changes over time.

The customer is using APIs to build a custom article management dashboard and would like to identify relationships between original articles and their replicated versions (replicated articles). Currently, there is no API field that exposes the source article ID or links a replica back to its original article. As a workaround, they are matching articles by title, which is not reliable since multiple articles can have the same name. The customer has requested API support to expose original-to-replica article relationships.

The customer is building a custom dashboard using Document360 APIs and relies heavily on article labels for team ownership and categorization. Currently, labels are not exposed through the API endpoints, forcing the customer to consider migrating labels to custom fields as a workaround. They have requested API support to retrieve article labels so they can continue using labels within their custom reporting and dashboard workflows.

Support JWT Bearer token authentication on the REST API with reader group access control Currently, the Document360 REST API only accepts a project-level api_token for authentication. This means any custom app integration (e.g., SAP BTP, Salesforce middleware, ServiceNow connector) that calls the API server-side gets full project access — there is no way to scope responses to a specific reader or reader group. Use case: An enterprise in the media industry built a custom SAP BTP Translation app to embed Document360 inside SAP Service Cloud V2. Their agents have different roles — some can see private articles, some cannot. Because the API only accepts api_token, all access control had to be implemented in their BTP code. Every new private article requires a manual update to the BTP access mapping. Request: Support Authorization: Bearer <jwt> on the REST API, validating the token and returning only the content of the reader's groups that are permitted to see — the same access control that the widget applies natively, but available for server-side API calls.

These fields should be available and queryable via API, so downstream systems, integrations, portals, and automations can consume the article classification metadata programmatically.

We would like to integrate with GitLab. Our goal is to fully automate the process through GitLab pipelines, so that no manual file uploads or link sharing is required. However, the Drive endpoint currently has a 40 MB limit, which does not meet our requirements. We would like to request an increase in the limit to 500 MB for our use case. Thank you.

The Get Article endpoint provides the workflow status, but this would be much more helpful to us if we could also see who the workflow status is assigned to because we have many contributors. Also, we categorise our articles internally using labels, so the label information would also be very helpful it it was also included in the endpoint. Thanks for considering this request.

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.

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.

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