Webhooks

Overview

Webhooks let your Taskade automations communicate with the outside world in both directions:

• Inbound webhooks — external services send data into Taskade to trigger automations.
• Outbound HTTP requests — automations call out to external APIs as action steps.
• Receiving Taskade events — combine a Taskade trigger (e.g. task completed) with an outbound HTTP action to push events to your app.

Two ways to receive Taskade events:

• No-code: build an automation with a Taskade trigger plus an HTTP action — see Receiving Taskade Events below.
• Programmatic: register a signed outbound webhook with POST /api/v2/webhooks — see the Webhook Registration API. Available on Pro and above.

Inbound Webhooks

Receive data from any external service to kick off a Taskade automation.

How It Works

1. Create a webhook trigger in any automation flow.
2. Taskade generates a unique webhook URL for that trigger.
3. Configure your external service to POST JSON data to the URL.
4. The webhook payload becomes available as dynamic data in every subsequent action.

The webhook URL is generated per automation. You'll find it in the trigger configuration panel after selecting the Webhook trigger type.

Payload Structure

Any valid JSON body is accepted. Each field in your payload automatically becomes a dynamic variable you can reference in downstream actions.

Example payload:

{
  "event": "form_submitted",
  "name": "Jane Doe",
  "email": "[email protected]",
  "message": "Interested in a demo"
}

All four fields (event, name, email, message) are available as dynamic variables in your automation steps.

Authentication

Webhook URLs are unique and unguessable — each contains a cryptographically random token. For additional security:

• Validate incoming payloads in your automation logic (e.g., check for an expected event value).
• Rotate the webhook URL if you suspect it has been compromised by deleting and re-creating the trigger.

Treat your webhook URLs like passwords. Do not share them publicly or commit them to source control.

Bearer Token Authentication

For stronger protection on inbound webhook triggers, you can require callers to supply a secret bearer token. When enabled, Taskade rejects any request that does not present a valid token before the automation runs.

Setup:

1. Open the webhook trigger configuration panel in your automation.
2. Enable Bearer Token authentication and set a secret token value.
3. Taskade generates (or lets you enter) a secret — store it securely; it will not be shown again.

Calling the webhook:

Every inbound request must include the token in the Authorization header:

POST https://www.taskade.com/webhooks/<your-webhook-id>
Authorization: Bearer your_api_token_placeholder
Content-Type: application/json

{
  "event": "form_submitted",
  "name": "Jane Doe"
}

Requests that omit or supply an incorrect token receive a 401 Unauthorized response and are not processed.

Webhook automations are available on Pro and above. Free and Starter plans cannot create webhook triggers or subscriptions. See taskade.com/pricing.

Common Patterns

Outbound HTTP Requests

For outbound communication, use the HTTP Request action in any automation to call external APIs.

Configuration

Response data from the HTTP request is available as dynamic variables in subsequent automation steps — so you can chain API calls together.

Example: Post to an External API

Body:

{
  "channel": "#alerts",
  "text": "New task created: {{task.name}}"
}

Webhook Registration API

Requires Pro or above. Registration returns a signing secret exactly once — store it before anything else. The authoritative schema is the live Action API v2 spec.

Register signed outbound webhooks over the public API — no automation flow needed. Taskade POSTs the event payload to your endpoint and signs every delivery with an HMAC secret so you can verify it really came from Taskade. This is the same event stream the official Taskade integrations (Zapier, n8n, Activepieces) consume, and it replaces the legacy unsigned subscribeWebhook / unsubscribeWebhook operations (still available, now deprecated — see below).

Register a webhook

POST /api/v2/webhooks — one target URL, one or more events, optional workspace scoping:

POST https://www.taskade.com/api/v2/webhooks
Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN
Content-Type: application/json

{
  "targetUrl": "https://your-app.example.com/hooks/taskade",
  "events": ["task.due", "task.assigned"],
  "spaceIds": []
}

Response — secret is shown once:

{
  "ok": true,
  "webhook": {
    "id": "https://your-app.example.com/hooks/taskade",
    "url": "https://your-app.example.com/hooks/taskade",
    "events": ["task.due", "task.assigned"],
    "spaceIds": [],
    "createdAt": "2026-07-21T09:00:00.000Z"
  },
  "secret": "your_signing_secret_placeholder"
}

A webhook's id is its target URL — URL-encode it whenever you use it as a path parameter.

Supported events

Scope to specific workspaces

"spaceIds": [] (the default) delivers matching events from all your workspaces. Pass workspace ids to receive events from only those workspaces:

{
  "targetUrl": "https://your-app.example.com/hooks/taskade",
  "events": ["project.created"],
  "spaceIds": ["SPACE_ID_1", "SPACE_ID_2"]
}

List, inspect, delete

# list all registered webhooks
curl https://www.taskade.com/api/v2/webhooks \
  -H "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN"

# get or delete one — the :id is the URL-encoded target URL
curl -X DELETE \
  "https://www.taskade.com/api/v2/webhooks/https%3A%2F%2Fyour-app.example.com%2Fhooks%2Ftaskade" \
  -H "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN"

GET /api/v2/webhooks returns { "ok": true, "items": [ ... ] }; DELETE /api/v2/webhooks/{id} returns { "ok": true, "deleted": true }.

Verify delivery signatures

Every delivery carries an X-Taskade-Signature header — sha256= followed by the hex HMAC-SHA256 of the raw request body, keyed with your webhook's secret:

X-Taskade-Signature: sha256=5f4dcc3b5aa765d61d8327deb882cf99...

Recompute the HMAC over the raw body (before any JSON parsing) and compare in constant time:

import crypto from "node:crypto";

function verifyTaskadeWebhook(rawBody: Buffer, signatureHeader: string, secret: string): boolean {
  const expected = `sha256=${crypto.createHmac("sha256", secret).update(rawBody).digest("hex")}`;
  return (
    expected.length === signatureHeader.length &&
    crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signatureHeader))
  );
}

Reject any delivery whose signature doesn't match.

Limits & requirements

Legacy: unsigned subscriptions (deprecated)

POST /api/v2/subscribeWebhook ({ targetUrl, triggerType } -> { ok, hookId }) and POST /api/v2/unsubscribeWebhook ({ hookId }) still work, but they are deprecated: each subscription covers a single event, scoping is account-level only, and deliveries are not signed. New integrations should use POST /api/v2/webhooks; existing ones can migrate by registering the same target URL with the new endpoint and removing the old subscription.

Receiving Taskade Events

To notify your app when something happens in Taskade (a task is added, a task is completed), build an automation that starts with a Taskade trigger and ends with an Outbound HTTP Request to your endpoint. The trigger's fields are available as dynamic variables in the HTTP body.

Common triggers and their payloads

Task added — fires when a new task is added to a project:

{
  "projectId": "abc123",
  "nodeId": "node_456",
  "nodeText": "Follow up with client",
  "projectTitle": "Sales Pipeline",
  "nodeNote": "Optional note text",
  "projectLink": "https://www.taskade.com/d/abc123",
  "assignees": [ { "handle": "jane" } ],
  "startDate": "2026-06-10",
  "endDate": "2026-06-12"
}

Task completed — fires when a task is marked complete:

{
  "projectId": "abc123",
  "nodeId": "node_456",
  "nodeText": "Follow up with client",
  "projectTitle": "Sales Pipeline",
  "projectLink": "https://www.taskade.com/d/abc123",
  "completedBy": "jane",
  "completedAt": "2026-06-11T14:30:00Z",
  "triggerTime": "2026-06-11T14:30:01Z",
  "assignees": [ { "handle": "jane" } ]
}

Custom field values on the task are included as additional keys. Other triggers (new comment, due date, project completed, schedule) follow the same pattern — see the Action & Trigger Reference.

Rate Limits

Excessive inbound webhook calls may be throttled to protect system stability. If you expect high-volume webhook traffic, consider batching events or adding a queue on the sender side.

Next Steps

• Authentication — set up API tokens for outbound requests
• Native integrations — prefer a built-in connector over raw webhooks for supported services; for an arbitrary MCP server, use outbound MCP