Public API

Firts of all love the official Clickup MCP server. Our SDLC workflow has been trasnformed with it. One issue we seeing is it uses 34K tokens and that's roughly 17% of claude's 200K context window. Any optimisation that can be done ? Screenshot is from Claude code's "/context" command.

I need to be able to use the internal API to extract the history of a task as it is displayed on the web. After some research, I found that this functionality already exists, but it is not exposed via the public API and can be extracted from the internal web API.

It would be extremely helpful if ClickUp API supported retrieving all task activities/history items through its endpoints. It helps tracking impactful changes on the tasks made by users.

We just started using synced content (a great feature!), but the REST API has no way to read it. Any integration, export or backup built on Get Task silently loses synced text and images. Endpoint GET /api/v2/task/{task_id} GET /api/v2/task/{task_id}?include_markdown_description=true Problem When a task description contains a synced block, the response carries only a [sync-block:<uuid>] placeholder in description and text_content. markdown_description drops the block entirely, text and images included, with nothing left in its place. This happens in the task that created the block and in every task that shows it. No field returns the block's content or its source, and no documented endpoint resolves a sync-block UUID. Steps to reproduce In task A, add a heading with a synced block under it containing text and a pasted image. Show that block in task B's description. Call GET /api/v2/task/{A}?include_markdown_description=true, then the same for B and once more for A without the flag. Observed description and text_content are identical and contain [sync-block:<uuid>] at the block's position. The same UUID appears in A and B. markdown_description skips straight past the block. In A, the heading is followed directly by the next one (e.g. "# Goals\n\n# Implementation Plan"). include_markdown_description=true adds only the markdown_description key. No other field changes. No top-level key or nested path in the response contains "sync" or "block". Images pasted into the block appear in neither task's markdown. They're only in the uploading task's attachments, with nothing tying them to the block or its position. Expected (any one would do) markdown_description renders synced content inline, as the UI does, with images as links like other inline images. The response includes a synced_blocks array: UUID, source task/doc, and the content as markdown. An endpoint resolves a sync-block UUID to its content and source. Impact markdown_description gives no sign that content is missing, so consumers can't detect the gap. The only way to notice is to scan text_content for [sync-block: markers and compare against the UI. The Get Task reference doesn't mention synced blocks, so integrators have no documented way to handle them. The official MCP server's clickup_get_task inherits the same gap.

Description: Currently, while task descriptions support Markdown formatting through the API, long text Custom Fields do not. Implementing Markdown support for these fields would allow for consistent rich text formatting across tasks and Custom Fields, enhancing data presentation and user experience. ​I am working on replicating Azure DevOps' commit history view within ClickUp tasks for my team. To achieve this, I'm using a combination of Webhooks and the ClickUp REST API. Implementing Markdown support for long text Custom Fields via the API would greatly assist in this endeavor. Thanks!

The public API exposes task descriptions as description / markdown_description on read and description / markdown_content on write. Markdown is lossy in both directions: Reading flattens toggles, banners, columns, table formatting, and inline mentions. Synced Content disappears entirely. Writing can't produce any of those blocks. The markdown importer also inserts extra paragraphs in nested lists. Synced Content blocks have no endpoints at all. What I'm asking for A documented read/write field for structured description content on the task endpoints. The Quill { ops } format the web client already uses would be fine. Plus read/update endpoints for Synced Content blocks. A minimal version would go a long way: the v2 task endpoints already accept description: { ops: [...] } today, because that's what the web app sends. Documenting that behavior and committing to its stability would unblock most of this without new endpoints. I maintain an open-source ClickUp CLI (krodak/clickup-cli). I just had to turn down contribution related to this: https://github.com/krodak/clickup-cli/pull/144 I declined it as it relies on web app's private endpoints and a session JWT scraped from DevTools.

Ship an official ClickUp CLI as a deterministic alternative to MCP for agent workflows Problem We are building AI-driven workflows where agents run locally or in CI and need a tool surface that is: deterministic and cheap at runtime self-describing (so agents do not guess capabilities) stable across time (versioned contracts) MCP introduces overhead and token cost due to tool discovery and repeated schema/context exchange. We want a CLI-first interface that is always up to date and can be invoked by agents and automation systems. Request Please ship an official ClickUp CLI that wraps core ClickUp APIs and Automation Webhooks, with the following requirements: Help-first, machine-readable contracts clickup --help and clickup <cmd> --help must be complete and structured include input flags, examples, output schemas, and exit codes JSON by default All commands output strict JSON by default (--human optional) Stable schemas with versioning Stable exit codes 0 success 2 needs_input/validation error 3 blocked/permission/auth/rate limit 4 failed/unexpected Authentication OAuth device flow (ideal), plus optional support for personal tokens for power users Clear scoping to a workspace Core commands (v1) tasks get|search|create|update comments create|list lists get|search webhooks create|test (or automation webhook helpers) docs get|search (if feasible) Safety controls --dry-run to show mutations without applying explicit confirmation flag for destructive operations Auto-update / version pinning ability to force update before run (agent-friendly) ability to pin versions for CI reproducibility Why this matters This enables a “ClickUp as coordination layer” architecture where: ClickUp is the UI + state machine external agents/CLIs do deterministic work in codebases updates are written back to ClickUp reliably This is lower cost and higher control than MCP-style tool calling for many teams. Related Automation webhooks already exist and work well; a CLI would complement them as the execution surface.

Currently, we can post updates to Chat from ClickUp, though it would be good to reverse the process and when something is mentioned in Chat, we can create a task from that comment.

I would like to retrieve the history of changes for each task using the Public API. Currently, there is no public endpoint available to retrieve task history, including status changes, updates to the assigned person, priority changes, and other field changes. Could you please help me with this? This is one of the most requested features on your feedback page with hundreds of upvotes since 2020. Please prioritize this feature.

We utilize a variety of custom fields in our workflows and we are constantly adding options to fields like dropdowns and labels to ensure consistency and "exact match" for some variable items within our project tracking. For Example, "Client Code" is a dropdown to mitigate human error in manual entry. As new clients come online, we can automate MOST of the onboarding process but still need to add these options to the dropdown lists manually. It would sure be swell if this was something we could tie into the automations to create new options automatically.