---

name: clickup-upgrade-migration description: >- Migrate ClickUp endpoints, schemas, clients, and terminology with version inventory, dual contracts, canaries, and rollback. Use when adopting selected API v3 surfaces or provider changes. Trigger with "upgrade ClickUp API", "ClickUp v3 migration", or "ClickUp schema change". argument-hint: "[repository-path] [target-endpoint-or-version]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.8.0 author: Jeremy Longshore jeremy@intentsolutions.io license: MIT tags:

• saas
• clickup
• upgrade model: inherit effort: high compatibility: Designed for Claude Code; live canaries require authorized non-production ClickUp access

---

ClickUp API Evolution Migration

Overview

Evolve endpoint-by-endpoint because ClickUp v2 remains the primary surface while selected capabilities use v3. Never infer a platform-wide cutover from one migrated endpoint.

Prerequisites

• An inventory of every endpoint, version, field assumption, pagination loop, and webhook dependency
• Pinned current/target OpenAPI schemas and representative sanitized fixtures
• Feature flags, canary environment, reconciliation, and rollback ownership

Tool Discipline

Use Read, Glob, and Grep to inspect the repository, adapters, configuration names, tests, and evidence. Use WebFetch only for current official ClickUp documentation. Use Write or Edit after confirming the target file, Workspace boundary, and requested mode.

Current Contract

• There is no general v2-to-v3 cutover contract; preserve explicit version routing for unchanged v2 operations.
• v2 uses Team for Workspace while v3 uses Workspace; Groups remain user groups.
• Different endpoints can have different pagination and response types, so a base-path swap is unsafe.
• Preview or experimental surfaces require tighter pins and rollback.

Authentication

Use a personal token only for accountable individual/testing work or OAuth Authorization Code for a user-facing integration. Inject the token server-side through a governed secret reference, send it in Authorization, verify authorized Workspace IDs, and never print the token, OAuth client secret, or webhook secret.

Instructions

1. Inventory current operations and label each v2, v3, deprecated, preview, or unknown.
2. Diff official schemas and docs for path, auth, plan, parameter, field, pagination, and error changes.
3. Update typed adapters behind a feature flag while preserving the current path.
4. Run offline dual-contract fixtures and migration tests, including nulls and partial failures.
5. Canary read-only traffic, then separately approved synthetic writes, and compare normalized results.
6. Promote endpoint-by-endpoint or roll back; update evidence and remove old code only after stability.

Approval Boundaries

Do not globally replace /api/v2, silently coerce fields, auto-fallback writes, or remove the rollback path before the stability window.

Output

Return operation inventory, schema delta, compatibility decisions, test/canary results, rollout state, rollback, and unresolved risks.

Error Handling

Condition	Response
Target endpoint is not generally available	Keep the current path and record the prerequisite.
Normalized results differ	Stop promotion and investigate semantics.
Rollback data is incomplete	Do not enable writes.
Terminology change alters tenant routing	Fail closed on Workspace mismatch.

Examples

The example below is a redacted operator receipt; it contains no task text, member data, credential, or webhook secret.

target=v3-auditlogs; v2-operations-retained=14; schema-tests=pass; read-canary=pass; write-canary=not-applicable

Resources

• Skill-specific official documentation
• API v2 and v3 terminology
• Authentication
• Rate limits