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.

Hello ClickUp Team, We are currently building a deep, real-time synchronization between Jira and ClickUp using your powerful API. The goal is to maintain a perfect mirror of our issues, including their comments and attachments. We've successfully implemented create and update operations, but have hit a significant roadblock: the API lacks an endpoint to delete an individual attachment. When an attachment is deleted in Jira, we have no direct way to replicate this action in ClickUp. This forces us to rely on complex and indirect workarounds (like using internal automations triggered by comments), which are less reliable than a dedicated API call. A DELETE operation for attachments is a fundamental part of a complete CRUD API and a standard feature in comparable platforms. Its absence not only complicates integrations but also leads to a significant accumulation of obsolete and orphaned files within ClickUp tasks. Over time, this results in unnecessary data being stored on ClickUp's servers and clutters the workspace for our users. We believe adding this functionality would be a major improvement for any team relying on your API for synchronization. Use Case Example: Scenario: A user deletes an attachment in Jira, and the change is synced to ClickUp Given a task in ClickUp with attachment ID "attachment_123" that is synced with a Jira issue When a user deletes the corresponding attachment in Jira Then our integration should be able to make a DELETE /api/v2/attachment/attachment_123 call to successfully remove it from the ClickUp task. Thank you for considering this important feature. Best regards,

There are a few events available to subscribe in API webhook but more would be nice. For example to receive a webhook whenever someone react (emoji) to a comment, or someone reply to a comment. The current events to subscribe are available here: https://clickup.com/api/developer-portal/webhooks/ Add more events to subscribe: Emoji reaction Reply to comment

The ability to include mentions in comment text or task descriptions

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.