Feature Requests

When reading or writing Doc pages via the API or MCP server, only text/md (Markdown) and text/plain are supported as content formats. This means that any rich formatting applied in the ClickUp editor — such as colored text, callout blocks, banners, column layouts, and other editor-specific elements — is lost when a page is written back via the API or MCP. This creates a real problem for AI assistant workflows (e.g. using the official MCP server with Claude or other LLMs): if a Doc page has been carefully formatted in the ClickUp editor, any AI-assisted update to that page will strip all of that formatting, since the only write path available is Markdown. What I'd like: Either (or all) of the following: * idea 1: A richer content format option (e.g. text/html or a ClickUp-native rich text AST) for both reading and writing Doc pages, so that formatting round-trips cleanly. * idea 2: A read-only rich format so that the original formatting can be fetched and preserved when writing back — even if writes remain Markdown-only. * idea 3: An API / MCP tool to insert in a doc at a certain position, so we can just update selected part without rewriting the whole doc (added value: likely to save tokens) Use case: Using the ClickUp MCP server with an AI assistant to append or update content in Doc pages that were formatted in the ClickUp editor. Currently, doing so risks destroying the existing visual structure of the document.

The Docs API currently supports creating and editing pages, but there's no endpoint to delete a page from a Doc. We're syncing content from an external CMS to ClickUp Docs. When content is deleted in our CMS, we'd like to remove the corresponding page in ClickUp via the API. Currently our only workaround is renaming the page with a [DELETED] prefix — the page still exists and has to be cleaned up manually. A DELETE /api/v3/workspaces/{workspace_id}/docs/{doc_id}/pages/{page_id} endpoint would complete the CRUD lifecycle for the Docs API.

Before ClickUp 4.0, guests with edit permissions were able to create new Docs directly in the Docs Hub, even when the document was not linked to a Space, Folder, List, or Task. After the 4.0 update, guests can still view and edit existing Docs, but they can no longer create new ones in the Docs Hub. This change was not clearly communicated and broke established workflows that relied on guest collaboration. We are requesting the ability to allow guests to create new Docs in the Docs Hub again, restoring the previous behavior or providing a configurable permission for workspace admins. Problem / Why this matters Many teams use guests for: External consultants Partners Auditors Designers Engineers or specialists working on documentation In these scenarios, guests are expected to: Create meeting notes Draft procedures (SOPs) Propose documentation Collaborate asynchronously Blocking Doc creation forces teams to: romote guests to full members (higher cost) Create Docs on their behalf Use workarounds like templates and duplication This negatively impacts collaboration, governance, and efficiency. Expected behavior Workspace admins should be able to: A) Allow guests to create Docs in the Docs Hub OR B) Enable a specific permission like: “Allow guests to create Docs” This permission could be optional and disabled by default for security-conscious teams. Actual behavior (ClickUp 4.0) Guests can edit existing Docs Guests cannot create new Docs in Docs Hub Docs created by guests before 4.0 still exist No clear permission toggle or documentation explains the change Business impact Increased friction in collaboration with external contributors Higher costs due to forced member upgrades Reduced adoption of ClickUp Docs for shared documentation More “manual proxy work” by internal team members Additional context This feature existed and worked well before ClickUp 4.0. Restoring it (or making it configurable) would align ClickUp Docs with real-world collaboration needs while still preserving security controls.

The ClickUp API, when used with Markdown to update text like Docs or Task Descriptions, adds line breaks that aren't part of the original markdown. For example, it adds line breaks after every heading and after every bullet section. Please fix the automatic addition of these line breaks to more closely match the original content. This affects: Migrating Docs and content from other platforms to ClickUp Automatic workflows using tools like Zapier or n8n

Allow preview of docs similar to PDFs so a download is not necessary each time.

We should have the ability to export all docs on a space / folder / list / basis in bulk instead of having to do them all individually.

Doc as a web page without the ClickUp logo, simple as that! 😉

Docs and notepad pages could have customizable properties on them to help mark documents/pages that are in draft status, need review etc. They could also be tagged to denote teams or even document types etc.

Are there any plans to improve search. I've been trying to integrate ClickUp into our workflows. We've made a number of attempts with different teams. But while authoring docs is OK, could be better as posted elsewhere. Or real issue is that once we have rich multi page docs, books, the searching is practically useless. At best you get a page reference. almost any other search tool will take you to the page and the parts of the page holding your search phrases and will support a rich FTS search model of phrases, or regex.

On the Clickup docs, I would like to set the default with a page width as 'full' so there is less white space on the margins. The default has margins which are way too big. I know how to do this for individual docs and then apply that typography to that folder; but I would like the ability to change the default at the workspace level. because our whole organisation wants the default to be 'full' so it seems odd that we cannot set this as a default. Is this likely to happen soon?