Taiga trigger

Overview

Receives webhook notifications from Taiga when project management events occur, such as issue creation, user story updates, task changes, milestone modifications, and wiki page edits. Taiga sends a POST request containing the action performed (create, change, delete), the resource type (issue, userstory, task, milestone, wikipage), the user who performed the action, the timestamp, and the full resource data. Supports filtering by resource type and operation type. The webhook payload includes the complete object data in the data field. Useful for syncing agile project updates, triggering notifications on sprint changes, automating task tracking, and integrating Taiga with other project management or communication tools.

Node Type

Trigger — webhook (receives incoming HTTP callbacks)

Input / Output

Direction	Port(s)
Input	None (trigger node)
Output	Output

Credentials

This tool requires Taiga credentials. See the Credentials Guide for setup instructions.

Parameters

Parameter	Type	Required	Default	Description
Project ID	string	Yes	—	The Taiga project ID to listen for events on. You can find the project ID in your Taiga project settings or URL.
Resources	multiOptions	Yes	["all"]	Which resource types to listen for. Select “All” to receive events for all resource types.
				Options: all, issue, milestone (a sprint), task, userstory, wikipage
Operations	multiOptions	Yes	["all"]	Which operations to listen for. Select “All” to receive events for all operation types. Note: “Update” maps to the “change” action in Taiga webhooks.
				Options: all, create, delete, change (shown in the editor as Update)
Accept Unsigned Requests	boolean	Yes	false	Required. Taiga has an upstream bug (taiga-back#1031) that makes its webhook signature header unverifiable, so this trigger authenticates callers by the secrecy of the webhook URL alone. Turn this on to acknowledge that and start receiving events; while it is off every delivery is rejected with 401.

Output Data

Each accepted event produces one output item:

• action — the Taiga action, one of create, change or delete
• type — the resource type the action applied to, e.g. issue, userstory, task, milestone, wikipage
• by — the Taiga user who performed the action
• date — the timestamp Taiga recorded for the action
• data — the full resource object as sent by Taiga
• _trigger — always taiga_webhook
• _timestamp — ISO 8601 timestamp of when the event was received
• _webhookEvent — the resource type and action joined with a dot, e.g. issue.create

Events whose resource type or operation is outside your selection are acknowledged to Taiga but do not start the workflow.

Reference the payload downstream by expression, e.g. {{ $json.data.subject }}.

Example Configuration

Listen for every event on a project:

{
  "type": "taiga_trigger",
  "parameters": {
    "projectId": "12345",
    "resources": ["all"],
    "operations": ["all"]
  }
}

Fire only when a new issue or user story is created:

{
  "type": "taiga_trigger",
  "parameters": {
    "projectId": "12345",
    "resources": ["issue", "userstory"],
    "operations": ["create"]
  }
}

Track sprint (milestone) updates and deletions:

{
  "type": "taiga_trigger",
  "parameters": {
    "projectId": "12345",
    "resources": ["milestone"],
    "operations": ["change", "delete"]
  }
}

Trigger Behavior

• Activation: When the workflow is activated, a webhook endpoint is registered with the service.
• Deactivation: The webhook is automatically unregistered when the workflow is deactivated.
• Payload: The incoming webhook payload is parsed and output as workflow items.
• Verification: Supports signature verification where applicable.

Tips

Entry point that fires when Taiga sends a webhook for project events. Configure the project ID, select which resource types to listen for (issues, tasks, user stories, milestones, wiki pages, or all), and choose which operations to track (create, update, delete, or all). The webhook payload includes the full resource data, the action performed, and the actor who made the change.