Public API

The ClickUp API has no mechanism to suppress notifications when updating tasks. Every API call to PUT /task/{task_id} or POST /task/{task_id}/field/{field_id} generates a notification to all task watchers. There is no query parameter, header, or flag to prevent this. Why this is critical: Any organization automating workflows via the ClickUp API at scale hits this wall. Our example: we manage 200+ projects in Professional Services. A daily n8n automation propagates metadata (Customer Name, Project Code, Region, etc.) from a master task to hundreds of sibling tasks. Every field write notifies every watcher, creating a flood of irrelevant notifications that bury relevant updates.

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.

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.

I want to add fields that I can update with the API, like Email, ratings, etc.

The V2 OpenAPI spec at https://developer.clickup.com/openapi/clickup-api-v2-reference.json has incorrect type definitions for several task response fields. This causes JSON deserialization errors in any code generated from the spec. **Issue 1: time_spent and time_estimate declared as string|null , API returns integer ** Affected endpoints: GET /v2/task/{task_id}, PUT /v2/task/{task_id}, POST /v2/list/{list_id}/task, and others. Spec declares: {"type": ["string", "null"]} API actually returns: "time_spent": 3600000 (integer, milliseconds) Error when using generated code: json: cannot unmarshal number into Go struct field UpdateTaskJSONResponse.time_spent of type string Fix: Change to {"type": ["integer", "null"], "description": "Time in milliseconds"} **Issue 2: assignees and tags declared as string[] , API returns object[] ** Spec declares: {"type": "array", "items": {"type": "string"}} API actually returns: assignees: [{"id": 123, "username": "isaac", "email": " isaac@example.com ", ...}] tags: [{"name": "bug", "tag_fg": "#fff", "tag_bg": "#f00"}] Fix: Change items to proper object schemas with the fields the API actually returns. These mismatches affect all task-related endpoints. The V3 spec does not have these issues. Verified against spec version last-modified 2026-04-02.

Add an API endpoint to link a Document & Task. This allows the Document to be viewed in the "Doc Links" sidebar in the right-hand sidebar of tasks, and "Relationships" sidebar in the right-hand sidebar of documents.

This would be helpful in creating custom external AI workflows that integrate with all tasks and the knowledgebase of the company

I just tried to create a new sprint folder and set the first sprint on the same index as our other sprints (Sprint 15 for 31/07/23 to 12/08/23) but ClickUp won't let me choose to start on Sprint 15, I'm forced to start on Sprint 1. I had to duplicate another sprint folder without the tasks to get what I want. I don't understand why it was possible before and not anymore. It is useful, we need this feature.

When creating or updating tasks via the API using markdown_description, extra vertical spacing (empty line) is added between different block types: heading to text, text to heading, text to bullet list, and bullet list to text. Consecutive bullet points and consecutive text lines render correctly without extra spacing. The same content typed manually in the editor does not produce this extra spacing. Confirmed with both direct REST API calls and the MCP connector, same behavior. It would be useful to either fix this so the API renders the same as the editor, or provide an option/parameter to control paragraph spacing in markdown_description (e.g. a compact_markdown flag or similar).

Both clickup_get_time_entries and clickup_get_task_time_entries are broken due to a tags field type mismatch in the output schema. Root Cause: The ClickUp API returns tags as an array of objects ( [{name, tag_fg, tag_bg, ...}] ), but the MCP output schema defines it as string[] . This fails structured content validation. Symptoms: get_time_entries : Throws MCP error -32602 with "expected": "string", "received": "object" for every entry. In our test, the API successfully returned 206 entries but all were rejected by validation. get_task_time_entries : Silently returns empty results ( {"timeEntries": [], "total": 0} ) on tasks that have confirmed tracked time via get_task ( time_spent > 0 ). Verified across multiple tasks. Fix: Update the output schema for both tools to define tags as an array of objects. Note: These tools were working via Claude.ai in mid-March 2026. This may also explain Gretchen Elliott's March 17 report in this thread — get_time_entries does exist as an MCP tool but is currently unusable.