Event

trigger.taiga_event

TriggerBusiness appsconnection requiredruns in-engine

Registers a webhook in the tenant's Taiga project on publish and starts one run per delivery, verified against Taiga's HMAC-SHA1 signature.

Start a run when something changes in a Taiga project — an issue, user story, task, sprint or wiki page.

Ask about Taiga All Taiga nodes Provider API docs ↗

Connection

Required: Yes — the node will not save without one
Auth type: Bearer token
Providers: Taiga
Secret shape: the Taiga auth token as {"auth_token": "…"}, or {"username": "…", "password": "…"} to log in with
Config it needs: base_url
Resolved by: config.connection_id, else node.connection_id
Note: The account must be able to administer the project's webhooks — a member without that right can read issues and still fail to publish. Publishing also needs MANTLE_APP_PUBLIC_BASE_URL set to a URL the Taiga instance can reach, which for a self-hosted Taiga behind a firewall is the usual reason a registration succeeds and no delivery ever arrives.

Configuration

2 fields, 1 required. A dotted path is a nested object and name[] an array of objects — the editor renders the same tree.

Field	Type	Required	Default	Constraints	Example
project Id of the Taiga project to watch — the numeric primary key, not the project slug. Taiga has no per-event subscription, so the webhook fires for every object in this project; branch on 'type' and 'action'.	integer	Yes	—	≥ 1	12
name What the webhook is called in the project's settings, so whoever finds it there knows where it came from.	string	No	Mantle workflow trigger	1–250 characters	—

Example configuration

Every value below is the contract’s own example or default — nothing invented.

{
  "name": "Mantle workflow trigger",
  "project": 12
}

Output

One shape.

taiga event

The flattened Taiga delivery. data's own keys vary by type, so the shape is open below the declared fields.

Extra keys beyond the ones listed can appear.

Field	Type	Example
type Which kind of object changed — milestone, userstory, task, issue or wikipage. A Taiga webhook fires for the whole project, so this is what a workflow branches on.	string	issue
action What happened to it: create, change or delete.	string	create
date When Taiga raised the event, as an ISO-8601 timestamp. Part of the idempotency key, never used as a clock.	string	2026-04-12T12:00:56.335Z
by.id Id of the Taiga user who caused the event.	number	6
by.username That user's username.	string	user1
by.full_name That user's display name.	string	—
object_id Taiga's internal primary key for the changed object, lifted out of data so the next node need not dig.	number	118
object_ref The per-project reference number shown in the Taiga UI (#31), where the object has one. Null for a wikipage.	number	31
project_id Id of the project the object belongs to.	number	12
subject The object's one-line subject, where its type has one. Empty for a wikipage, which has a slug instead.	string	—
permalink Taiga's own URL for the object.	string	—
version The object's optimistic-concurrency version — send it back on a taiga.update_issue so Taiga can refuse a stale write.	number	1
change On a 'change' action, Taiga's diff block (comment, edit_comment_date and a 'diff' of the fields that moved). Empty on create and delete.	object	—
data Taiga's own object, verbatim. Its keys depend on type, which is why this shape is open.	object	—
payload The delivery envelope exactly as Taiga sent it, for anything the fields above do not lift out.	object	—

{
  "action": "create",
  "by": {
    "full_name": "Purificacion Montero",
    "id": 6,
    "username": "user1"
  },
  "change": {},
  "data": {
    "id": 118,
    "project": {
      "id": 12,
      "name": "Acme",
      "slug": "acme"
    },
    "ref": 31,
    "subject": "Checkout returns a 500 on retry",
    "version": 1
  },
  "date": "2026-04-12T12:00:56.335Z",
  "object_id": 118,
  "object_ref": 31,
  "payload": {
    "action": "create",
    "type": "issue"
  },
  "permalink": "https://tree.taiga.io/project/acme/issue/31",
  "project_id": 12,
  "subject": "Checkout returns a 500 on retry",
  "type": "issue",
  "version": 1
}

Notes

Publishing creates the webhook in Taiga; unpublishing, disabling or archiving deletes it. A workflow that is off is off at Taiga too.
A Taiga webhook is per project and cannot be narrowed to one event type — every create, change and delete in the project starts a run, so branch on 'type' and 'action' early.
Deliveries are verified against Taiga's X-TAIGA-WEBHOOK-SIGNATURE, an HMAC-SHA1 over the raw body; an unsigned or mis-signed POST is refused with 401 before any run starts.
Taiga sends no delivery id, so a redelivery is recognised from the event's own type, action, object id, version and date.

Related Taiga nodes

See Event run in a workflow.

In a technical demo we add the Taiga connection, drop the node on the canvas and let Workflow Health pre-flight it before the first real run.

Book a technical demo Talk to sales