Feature Request

We want to filter out archived articles in our service so the Eduphoria team doesn't spend time reviewing updates to articles that have been archived in Document360. Would it be possible to expose the archived status shown in the screenshot in the Articles API? The existing archived and hidden fields do not appear to reflect the status shown in the screenshot. This would help us identify and exclude archived articles from the updates processed by our service. Thanks.

When the Knowledge base widget’s request to retrieve widget settings fails because of an incorrect or outdated API key, the error returned does not indicate that the key is the cause, making it difficult to identify the root cause of a failing widget. Update the widget settings API response so that a key-related failure returns a specific, descriptive error (for example, indicating an invalid or mismatched API key) rather than a generic error message that does not point to the actual cause. Benefit: Users can identify and resolve API key issues on their own more quickly, reducing the time a widget spends in a non-working state.

Feature description: The customer would like an API endpoint that allows them to replace an existing file in Document360 Drive without having to upload it as a new file or manually replace it through the UI. Use case: The customer wants to programmatically update existing files in Drive, making it easier to maintain files and their content through API integrations and automated workflows. Expected behavior: Provide an API endpoint to replace an existing file in Drive. Allow users to identify the existing file and upload its replacement through the API. Preserve the existing file reference, where technically feasible, to avoid having to update links or references wherever the file is used. Customer impact: This would improve automation capabilities, reduce manual effort, and simplify file maintenance for customers managing Drive content programmatically.

We request you to provide an option to support running the Document360 CLI (d360) within Bitbucket Pipelines. This should include a sample bitbucket-pipelines.yml configuration, setup instructions, and details of any known limitations. Additionally, consider a native Bitbucket integration to simplify CI/CD workflows for teams using Bitbucket.

Teams that automate their API documentation workflow have no way to detect, in real time, when an API reference is imported, resynced, or edited. Neither the webhook/notification event list nor the team-auditing event list includes any event type for this activity, unlike standard articles and categories, which are both fully covered. Add API reference import, resync, and edit actions as trackable event types in both the notification mapping system and team auditing, following the same pattern already used for article and category events (for example, “API reference imported,” “API reference resynced,” “API reference edited”). Benefit: Teams could automatically trigger downstream workflows, such as cache invalidation, release tracking, or custom automations, whenever an API reference changes, and would gain the same real-time visibility into API reference activity that they already have for standard articles and categories.

Projects created after API Keys (v3) launched can only create API keys scoped by portal role and content-access role. There is no way to generate a single, project-wide credential restricted only by HTTP method, independent of any role or content scope. Add an option, available regardless of a project’s creation date, to generate a project-wide API credential restricted only by HTTP method (GET, POST, PUT, DELETE), with no role or content-scope configuration required. Benefit: Administrators could connect simple, method-based integrations without first configuring granular portal and content roles, and could build or migrate automations that depend on a single, unrestricted, method-scoped credential rather than a role-scoped one.

The API keys list does not show who created each key, making it difficult for a team to identify which keys belong to which integration or team member. Display the creator’s name alongside each key’s name, role, and last-used date on the API keys page. Benefit: Teams can independently identify and manage keys created by different team members or integration partners, without needing to track that information outside the product.

We set article status badges through API v3 (PATCH /v3/articles/{id}/settings with status_indicator), and it works well. The Custom badge is the exception: its label is a localization variable, and as far as we can tell, no API can read or change it. GET /v3/projects/{project_id}/localization-variables returns a 404. So when we set a badge to custom through the API, we can't check what readers will actually see without opening the portal. Could you add v3 endpoints to list and update localization variables, per language? Even read-only access to the status badge labels would help.

Provide an API endpoint for the semantic search functionality currently available through the Document360 MCP Server. This would allow applications such as BigID to authenticate using an API key and perform semantic searches and retrieve relevant articles without relying on the MCP OAuth flow. This would also support machine-to-machine integrations and automated workflows. Thank you.

Release 12.9.3 added file renaming in Drive (see Drive should allow us to rename image files). Please make the same action available in the API. PATCH /v3/projects/{project_id}/drive/files/{file_id} { "file_name": "new-name.png" } Expected behavior: Same result as renaming in the portal: articles, content reuse blocks and decision trees that use the file keep working. The response returns the updated file, including its new URL if the URL changes. A clear error if the name is invalid or already taken in the folder. Optionally, accept a new name on the existing move and copy endpoints as well.