Same problem here, +1.

We hit this building a CRM for a law firm on ClickUp. Every contract task links to a client, and the obvious modeling is a "Client" dropdown. But each new client means someone has to stop, open the UI, and add the option before any automation can create the contract. That one manual step breaks the whole client-onboarding flow — which was the reason we automated it in the first place.

Before commenting we ran the API directly, with an owner-level personal token, to be sure it wasn't a permissions issue on our side:

PUT /v2/field/{field_id} -> 405 Method Not Allowed

PATCH /v2/field/{field_id} -> 403 FIELD_262 "Access denied for updating field api"

POST /v2/list/{list_id}/field -> 200 (creating a field works fine)

/v3/.../customFields -> 404 (no v3 equivalent)

The PATCH result is the interesting one. It's a 403, not a 404 or 405 — the endpoint is there, it's just closed to API credentials. Note the word "api" inside the error message itself.

That lines up exactly with what Francisco described above: the front-end reaches this endpoint with a session JWT. So the capability already exists and works — it's only gated by credential type. Nobody needs to build it from scratch.

One more angle worth flagging: this leaks into the MCP ecosystem now. Third-party ClickUp MCP servers ship an update_custom_field tool that calls PUT /v2/field/{id} — we called it and got the same 405. It's dead code that looks functional until you run it, so AI agents will keep planning around a capability that isn't there. ClickUp's own official MCP server doesn't expose the operation at all.

We're not asking for full CRUD. Just adding a single option to an existing dropdown, with an API token, would unblock most of the use cases in this thread — and it's the smallest possible version of this request.

Six years and four merged requests later, we'd take even a "no, and here's why" over silence. Happy to share the full test output if it helps.

We are also needing this to automate our release process. I am trying to keep our client to move to Github issues and this does not help.

+1 this should definitely be available in the API. Crazy it hasn't for so long!

Caroline Ginty Hi Carol, this is a feature we've all been waiting for for so long... wouldn't it be possible to include it in the roadmap?

I managed to simulate it somewhat and include it via API with a front-end endpoint, using a PUT request. However, it depends on a JWT token, meaning the automation breaks every time that token expires, making it unfeasible. But this shows how simple it is, because the endpoint itself, even if hidden in the front-end, already exists; it just needs adjusting and adding to the documentation.

I'm begging you, I've never asked you for anything... hahaha

just throwing my vote into this one as well. I agree with much of what is said and PARTICULARLY the part about the AI focus taking priority over core function. AI is cool but there are a billion options for it every day. Even "Brain Max" is just a wrapper of other platforms. Nice to have but expanded functionality in the API for easier dynamic maintenance is WAY more valuable to most users than another AI chatbot.

This is a huge shortcoming, no doubt about it! I’ve tried to work around the issue that so many have described here—the inability to build a truly dynamic system that can grow without forcing crazy manual workflows. Clients look at me like I have worms coming out of my ears when I tell them they need to manually add custom field dropdown items just to keep things running.

In my attempt to get around this, I tried using Relationship fields (which you can assign via API), but it turns out they’re practically useless since they can’t be used in formulas, Forms, or Dashboards.

Please, put the AI projects aside for now and focus on refining the core platform. We need a dynamic relational record system that users can actually maintain—without requiring a dedicated ClickUp admin.

Definitely need this!