A ClickUp automation webhook sends task events from ClickUp to another system the moment they happen, so tools like Make, n8n or your own server can react in real time. There are two ways to do it: create a webhook through the ClickUp API, which subscribes to events such as task created or status updated across a workspace or location, or use a ClickUp automation with a webhook action, which posts data only when a specific rule fires. Both send JSON to a URL you control.
I use ClickUp webhooks in several agency builds, including a client health monitor that routes alerts to the right customer success manager. Here is how the pieces fit.
Two kinds of ClickUp automation webhook
API webhooks
You create these with ClickUp's public API. You choose:
- The endpoint URL that will receive events
- The events to subscribe to, or all events
- Optional location filters, such as a space, folder, list or task, so you only receive events from part of the workspace
API webhooks are created with a user's token, so they are tied to that user. If that person loses access, the webhook can stop working. This is worth knowing before you set one up from a personal account.
The details are in ClickUp's webhook documentation.
Automation webhooks
ClickUp automations can include an action that calls a webhook. You build a normal automation, with a trigger and conditions, and the action sends a payload to your URL. This is useful when you only want to send data for a specific rule, such as "when the Health field changes in the Clients space". Availability depends on your plan, and these runs count toward your automation usage, so check ClickUp automation limits.
Which one to use
- Use API webhooks when you want broad, real-time event streams, such as every status change in a folder, and you are comfortable filtering on the receiving side.
- Use automation webhooks when you want ClickUp's own trigger and conditions to decide when to send, and volume is modest.
Common ClickUp webhook events
ClickUp's API offers task events such as task created, task updated, task deleted, status updated, assignee updated, due date updated, priority updated, task moved and comment posted, plus events for lists, folders, spaces and goals. Event names in the API use a camel case format such as taskStatusUpdated. Check the docs for the current list before you build, since it can change.
Task event payloads include history items that describe what changed, often with before and after values. That is how you tell, for example, that a status moved from In progress to Client review.
Verifying webhook signatures
When you create an API webhook, ClickUp returns a secret. Each delivery includes a signature header, and ClickUp's docs describe it as an HMAC SHA-256 hash of the request body using that secret, in hexadecimal. Your receiver should compute the same hash and compare. If you parse and re-serialize the body before hashing, whitespace changes can make the comparison fail, so hash the raw body.
Make and n8n custom webhook triggers do not verify ClickUp signatures for you automatically. For most internal agency workflows, a hard-to-guess webhook URL plus a filter on the expected workspace or location is a reasonable baseline. If the workflow writes to billing or client-facing systems, add signature checks, which you can do in n8n with a code step or in a small proxy.
ClickUp Make integration: the setup
Here is how I connect ClickUp to Make for a typical alert workflow.
- Create a custom webhook in Make. Add the Webhooks app's Custom webhook trigger to a new scenario and copy the URL.
- Point ClickUp at it. Either create an API webhook with that URL and the events you need, or build a ClickUp automation with a webhook action.
- Send a test event. Change a status or a field on a test task so Make learns the payload structure.
- Filter early. Add a filter right after the trigger so only the events you care about continue, for example status changes to a specific value.
- Fetch the full task if needed. Webhook payloads may not include every custom field. Use the ClickUp app's get task module, or an API call, with the task ID from the payload.
- Look up context. Pull the account owner, package or renewal date from Google Sheets or your CRM.
- Route and act. Use a Router to send alerts to different people or channels, create follow-up tasks, or update a sheet.
- Write back to ClickUp. Add a comment or update a field so the task shows that the alert went out.
- Add an error route that posts failures to an ops Slack channel.
The ClickUp app in Make also has its own watch triggers for some events, which can be simpler for basic cases. I prefer webhooks for anything time-sensitive.
Real example: client health alerts
On a live build for an agency, the trigger is a change to the health field in ClickUp. The webhook sends the event to Make, which:
- Checks the new health value
- Looks up the client in a Google Sheet to find the account owner and recent context
- Routes the alert by owner using a Router
- Posts to the right customer success manager in Slack
- Logs the alert in ClickUp
The team gets a targeted alert with context instead of a generic notification. You can see it on the client health monitor page, and I explain the scoring side in client health score for agencies.
ClickUp API automation beyond webhooks
Webhooks tell you something happened. The API lets you act. Common ClickUp API automation jobs I build for agencies:
- Create client folders and lists from templates during onboarding
- Update custom fields from external data, such as setting health from a reporting tool
- Create tasks from other systems, such as a failed-payment email or a positive cold-email reply
- Pull overdue tasks for a daily Slack digest
For authentication, ClickUp supports personal API tokens and OAuth apps. For agency automations I recommend a dedicated service user, so the integration does not break when someone leaves.
Mistakes to avoid with ClickUp webhooks
- Subscribing to everything. All events across a workspace can be a lot of traffic. Filter by location and event.
- No duplicate handling. Retries can deliver the same event more than once. Check whether you already handled it, for example by storing the event or history item ID.
- Personal tokens for production. Use a shared admin or service account.
- Trusting the payload for everything. Fetch the task if you need custom fields.
- Loops. If Make updates the same task that triggered it, the update can fire another event. Filter out changes made by your integration user.
- Ignoring webhook health. If your endpoint keeps erroring, deliveries can fail and the webhook may stop being useful. Monitor your scenario's run history.
How I build this
I build ClickUp webhook and API automations in Make for marketing agencies, mostly for alerts, onboarding and reporting. Health and billing alerts are part of the Agency Reporting and Alerts Pack. If you already have a webhook flow that drops events or loops, Automation Rescue fixes it in 48 hours. Or start with a free teardown.
FAQ
Does ClickUp support webhooks?
Yes. You can create webhooks through ClickUp's public API to subscribe to events like task created or status updated, and some plans also let a ClickUp automation call a webhook as an action.
How do I connect ClickUp to Make with a webhook?
Create a Custom webhook trigger in Make, register its URL as a ClickUp API webhook or in a ClickUp automation's webhook action, send a test event, then filter, look up data and route actions in the scenario.
How do I verify a ClickUp webhook signature?
ClickUp returns a secret when you create an API webhook, and each delivery carries a signature header. Compute an HMAC SHA-256 of the raw request body with the secret and compare the hex values.
Do ClickUp automation webhooks count toward automation limits?
Webhook actions inside ClickUp automations are automation actions, so they use your monthly allowance. API webhooks are part of the public API rather than the automations builder, so check ClickUp's docs for how your plan treats them.