Connector · Tasks and projects

ClickUp, in every client’s workflows.

Create a task, update a task, or start when a task is added to a list, with the client’s own ClickUp account.

Triggers: 2start a workflow
Actions: 2steps in a workflow

Start a workflow when something happens in ClickUpBeta

By webhook where ClickUp sends one, by checking where it does not. A webhook is checked once a day to see it is still on, and if ClickUp turns it off the alert carries a Reconnect button.

A task is added to a listPolledA new task in a list, checked every 5 minutes.
A task changes statusWebhookA task in a list moves to another status, within seconds. The Workspace ID is the first number in any ClickUp link.

Do it in ClickUp

A step with its own fields: values from the run go in by name, and what ClickUp answers is there for the next step.

Create a taskA task in a list.
Update a taskChange a task’s name, description or status, found by id. Fields left empty keep their value.

Connect the client’s ClickUp

On the client’s page in Thrum: Add credential, type ClickUp personal token.

In the client’s ClickUp: avatar → Settings → Apps → API Token → Generate.

The key is stored encrypted and bound to that client: another client’s workflow cannot use it, and no template or pack copies it.

ClickUp’s API documentation

Via HTTP

Or by web request: create a task in a list

For clients who run jobs in ClickUp: every request is a task with the caller’s details. The web request step, filled in: paste it, swap in the client’s ids, add their key.

01
Add the client’s credential
On the client’s page in Thrum: Add credential, type API key. In the client’s ClickUp: avatar → Settings → Apps → API Token → Generate → copy.
```
{
  "api_key": "pk_…"
}
```

Add a web request step

Name it “Add a ClickUp task”, set it as here, and pick the credential. Values in double braces are read from the run: here, the lead the form brought in.

LIST_ID: The number at the end of the list’s address: app.clickup.com/…/li/<id>.

{
  "method": "POST",
  "url": "https://api.clickup.com/api/v2/list/LIST_ID/task",
  "headers": {
    "Authorization": "{{ credential.api_key }}"
  },
  "body": {
    "name": "{{ lead.name }}: {{ lead.summary }}",
    "description": "{{ lead.phone }} · {{ lead.email }}"
  }
}

What goes out, and what comes back

A personal token has no “Bearer” in front: the header is the token itself.

POST https://api.clickup.com/api/v2/list/LIST_ID/task
content-type: application/json
authorization: ••••••••

{
  "name": "Nadia Karim: Quote for a new bathroom, two basins and a shower",
  "description": "+447700900222 · nadia@example.com"
}

200
{
  "id": "86a1b2c3d",
  "name": "Nadia Karim: Quote for a new bathroom, two basins and a shower",
  "url": "https://app.clickup.com/t/86a1b2c3d"
}

Watched like everything else

When ClickUp stops answering or refuses the client’s key, you hear about it, and your client does not.

A failing request: Tried 3 times, 5 seconds apart and doubling, only for errors a retry can fix
A service that asks for a pause: Given it, up to an hour
Requests at once, per account: 2, per worker; the rest wait their turn
Timeout: 15 seconds, unless the step sets its own
Private and internal addresses: Refused, on every redirect too
The client’s key: Encrypted, bound to the client, and kept out of every run record
A step that keeps failing: Marks the workflow Degraded and alerts you, not the client