Feature Requests

In the UI you are able to pin a note, this forces it to the top and is very useful. It would be great if this was possible to do via the API as well!

We use the Coperniq connector (MCP) in Claude to run a dashboard for our design team. It tracks D&E work, revisions, BOMs and ESR (our third-party engineer) planset uploads. A few gaps stop us from automating our planset check. list_project_files returns only the first 20 files. It returns the oldest 20 with no paging, so newer uploads like plansets in Docs › Engineering never come back. Please add paging (offset/cursor or page size), or a newest-first sort. No folder per file. Please return each file’s folder name or path (e.g. “Engineering”) and allow filtering by folder. No archived files. isArchived is returned, but archived files don’t seem to be included. Please add an option to include them. Comments are cut off at 20. list_project_comments returns 20 of 41 comments (totalCount is 41) with no way to get the rest. Please add paging. Reminders aren’t available. We’d like to list a project’s reminders with status, assignee and due date (e.g. “ESR Task Overdue”). Today we only see them through notification emails, so we can’t tell when one is resolved. Nice to have: rename and archive a project file through the connector (update_project_file). Then the planset check could fix the name, not just flag it. Why it matters: after each CAD Design Request or CAD Change Order, the planset PDF and zip in Engineering must be renamed “Project Name REVx” and older versions archived. Our BOM tool and other departments depend on that naming to pick the current planset. With items 1–3, our board can check this automatically and flag misses before a revision is closed. Thank you!

Expose archived work orders in the "List Work Orders" and in the "Get Work Order" endpoints.

The List Projects endpoint returns less data than Get Project. Anyone syncing projects in bulk has to make an extra Get call for every record just to fill these gaps. Missing from List (present in Get): projectManager updatedBy phase.startedAt / phase.completedAt phaseInstances (all phases with status and timestamps) Request: Include these fields in the List response, or add an option to request them (e.g. an include= parameter).

The List Users endpoint only returns active users, and there's no field showing whether a user is active. Please add an active field to each user and an option to include inactive users, such as includeInactive=true.

We need the ability for Coperniq administrators to restrict which users are allowed to create API keys. Currently, any Coperniq user can generate an API key, and the key inherits that user's existing permissions. While the permission scope of the API key is appropriate, allowing any user to generate persistent API credentials creates an additional security risk. Requested functionality Add a permission or role setting that controls access to API key creation. Ideally, administrators should be able to: Restrict API key creation to specific roles, such as Administrators. Prevent standard users from generating API keys. Continue allowing those users to access Coperniq normally according to their existing permissions. Allow administrators to manage who can create API keys without having to remove the user's normal project access. Ideally provide visibility into which users have generated API keys. Example A Sales user may have access to a limited set of projects in Coperniq. They should be able to access those projects normally, but they should not automatically have the ability to generate an API key that provides persistent programmatic access to those same projects. An administrator or designated integration user should be able to generate API credentials when required. Security consideration API keys are persistent credentials and can be used outside of the Coperniq UI. Even though the key inherits the creating user's permissions, allowing every user to generate API credentials increases the potential for unauthorized access or accidental exposure of Coperniq data. We would like API key creation to be treated as a privileged capability that can be restricted by an administrator.

The API allows labelling a Form but not a WorkOrder. This would be very helpful and it would be great to have this parity between object and between API vs UI.

Please add a paginated endpoint for retrieving Forms across all Projects, with support for filtering by the Form’s last update time. An ideal endpoint would look similar to: GET /v1/forms?page=1&page_size=100&updated_after=2026-08-01T00:00:00Z Useful response fields and filters would include: Form ID Project ID Work Order ID, when applicable Template ID Status Archived state Created timestamp Reliable updated timestamp Pagination updated_after and updated_before Optional Project, Work Order, template, and status filters If a global Forms endpoint is not feasible, an include_form_updates=true option on the Projects endpoint would provide a useful alternative. It should cause a Project to be returned when any attached Form is created, updated, completed, or archived, including changes to Form field values.

The UI allows for setting collaborators via the UI. It would be great if this was available in the API as well!

Currently, a Form’s updatedAt appears to change for updates such as status changes, but it does not change when the values of individual Form fields are edited. Please update updatedAt whenever any persisted part of a Form changes, including: Form field values Status Completion Archived state Assignee or collaborators Due date