Automate Taiga With n8n: 20 Operations, 6 Trigger Events

Why automate

What does the Taiga n8n integration actually do?

The Taiga n8n integration wires Taiga project boards into n8n workflows in both directions. The Taiga node covers 20 operations spread over 4 resources, epics, user stories, tasks and issues, so a workflow can create, read, update or delete any of them. The Taiga Trigger works the other way around: it registers a webhook, a URL that Taiga calls, and starts a workflow when something moves on the board.

First scenario, intake. A support form or an inbound message lands in n8n, a filter separates real bugs from noise, and issue.create files the issue in the right project with a priority and a severity already set. The same run can copy the new reference into Google Sheets so people who never open Taiga still see the queue.

Second scenario, sprint reporting. On a schedule, userStory.getAll pulls the stories of a milestone with Return All switched on, task.getAll pulls the tasks underneath, and the result lands in Postgres for a dashboard or goes out as a Monday digest in Slack.

Third scenario, two trackers that have to agree. The Taiga Trigger fires on the issue event, the workflow reads the payload and mirrors the change into GitHub. Run it the other way and a GitHub event becomes the Taiga issue instead.

When to reach for HTTP Request. The node exposes the 20 operations listed below. The Taiga API has endpoints beyond that list, and the HTTP Request node calls any of them while reusing the same Taiga credential through predefined authentication, so one login covers both nodes.

Two limits worth knowing before you build. On the four Get Many operations, Return All is what makes n8n walk through every page of results: leave it off and Limit caps what comes back, which is fine for a preview and wrong for an export. And every dropdown labelled Name or ID expects an identifier when you feed it from an expression, not the display name you read on the board. If n8n itself is new to you, the n8n review gives the wider picture.

Connect

How do you connect Taiga to n8n?

01
Create the Taiga credential
You need a Taiga account first. In n8n, open the Credentials menu and add a Taiga credential: the node authenticates with basic auth, so it asks for a Username, which accepts your username or the email address on the account, and a Password. A credential is created once and then offered in the dropdown of every workflow that uses Taiga.
02
Pick the right environment
The Environment field decides which Taiga the credential talks to. Cloud points at the hosted service. Self-Hosted points at your own install, and it adds a URL field where you enter the address of that instance. Get this pair right before testing anything: the rest of the setup depends on n8n calling the correct host.
03
Select the credential in the node
Drop a Taiga node or a Taiga Trigger into the canvas and choose the credential you just saved from its list. Both nodes accept the same one, so a workflow that listens and a workflow that writes share a single login. From there, pick the resource and the operation, and the Project Name or ID dropdown fills itself from your account.

Triggers

What starts a workflow from Taiga ?

Taiga Trigger is the node that starts a workflow when something happens in Taiga. It listens to 6 events, listed below by family. Pick one or several, activate the workflow: n8n registers the webhook on your Taiga account.

What you see in n8n

Every event, by family

One row per object, one chip per action. The event to tick in the node is object.action; hover a chip to read exactly when it fires.

all.*1

all.
- all

issue.*1

issue.
- issue

milestone.*1

milestone.
- milestone

task.*1

task.
- task

userstory.*1

userstory.
- userstory

wikipage.*1

wikipage.
- wikipage

Configuration notes

01Set up the Taiga TriggerThe Taiga Trigger is the entry point: it receives events from Taiga over a webhook, which is a URL that Taiga calls whenever something happens, and starts the workflow within seconds. No polling, so no interval to tune.

The Taiga Trigger is the entry point: it receives events from Taiga over a webhook, which is a URL that Taiga calls whenever something happens, and starts the workflow within seconds. No polling, so no interval to tune.

Key parameters

Project Name or ID: the project to watch, chosen from the list or given as an identifier through an expression. It is required, so one trigger covers one project.
Operations: the multi-select of what to listen to, required as well. Six values are available and you can tick several in the same trigger.

When to use it

whenever the workflow should react to the board rather than to a clock. Activate the workflow to register the webhook, and remember that a deactivated workflow stops receiving events.

02Issue eventsThe issue value sends the trigger every issue movement in the watched project. That is the bug and incident side of Taiga, and it is usually the noisiest of the six, which is exactly why it is worth routing carefully.

The issue value sends the trigger every issue movement in the watched project. That is the bug and incident side of Taiga, and it is usually the noisiest of the six, which is exactly why it is worth routing carefully.

Use cases

an incoming issue is checked against the on-call rota and a message goes to the right channel. Or the workflow reads the payload, calls issue.get for the full record, and writes a row into a reporting table so the response time can be measured later.

When to use it

for anything that has to happen fast after a bug is filed or touched. Pair it with a filter node early in the workflow, because one busy project can fire this event many times a day and you rarely want every one of them to reach the end of the flow.

03User Story and Task eventsTwo separate values, userstory and task, cover the delivery side of the board. Tick both in the same trigger when a workflow cares about the whole chain, or split them across two workflows when the reactions differ.

Two separate values, userstory and task, cover the delivery side of the board. Tick both in the same trigger when a workflow cares about the whole chain, or split them across two workflows when the reactions differ.

Use cases

a story moving is the cue to refresh a client-facing status page. A task moving is the cue to recompute what is left in the sprint, with task.getAll filtered on the milestone.

When to use it

for progress signals rather than alerts. These two carry the day to day rhythm of a team, so they feed dashboards, digests and handovers well. Keep in mind that the trigger tells you an event happened on that object type; when the workflow needs the current field values, a Get operation right after the trigger is the reliable way to obtain them.

04Milestone (Sprint) eventsThe milestone value fires on sprint level activity. In Taiga a milestone is the sprint container, so this event is the one that marks the beginning and the end of an iteration rather than the movement of a single card.

The milestone value fires on sprint level activity. In Taiga a milestone is the sprint container, so this event is the one that marks the beginning and the end of an iteration rather than the movement of a single card.

Use cases

when a sprint changes, a workflow can pull the stories attached to it with userStory.getAll and the milestone filter, then build the sprint summary nobody enjoys writing by hand.

When to use it

for rituals. Sprint review, retrospective preparation, capacity notes to a client. It is a low volume event compared with issues or tasks, which makes it a good candidate for workflows that end in a document or a long message, because you will not flood anyone. One trigger can carry it alongside other values if a single workflow handles several rhythms.

05Wikipage and All eventsTwo values close the list. wikipage reacts to the wiki side of a Taiga project, the pages where specs and decisions get written down. all is the catch-all: tick it and the trigger accepts every event type instead of a chosen subset.

Two values close the list. wikipage reacts to the wiki side of a Taiga project, the pages where specs and decisions get written down. all is the catch-all: tick it and the trigger accepts every event type instead of a chosen subset.

Use cases

a wiki change pushes a notification to the people who rely on that page. With all, one workflow collects everything and a Switch node sorts by type, which keeps the canvas small when several reactions share the same preparation steps.

When to use it

pick wikipage when documentation drift is the problem you are solving. Pick all when you would otherwise build four near-identical workflows. There is no wildcard character to type here; the all value is how you listen to everything.

Actions

What can the Taiga node do?

The Taiga node exposes 20 operations across 4 resources. For each one: the node as you configure it in n8n, the required fields, and our field notes.

Resources × operations matrix
Resource	Create	Get	Get Many	Update	Delete
Epic	✓	✓	✓	✓	✓
Issue	✓	✓	✓	✓	✓
Task	✓	✓	✓	✓	✓
User Story	✓	✓	✓	✓	✓

Epic

5 operations

01

Create an epic

epic.create

What you see in n8n

Notes & use cases

This operation opens a new epic in a Taiga project and returns the created epic, identifier included, ready for the nodes that follow.

Key parameters

Project Name or ID: the project the epic belongs to, picked from the list or passed as an identifier with an expression such as {{ $json.projectId }}.
Subject: the epic title, and the only other required field.
Color: in Additional Fields, a color code in hexadecimal notation, useful when each product area has its own color on the board.

Use cases

a quarterly planning sheet is read row by row and each line becomes an epic, labelled through Tag Names or IDs so the board is sorted from day one.

02

Delete an epic

epic.delete

What you see in n8n

Notes & use cases

Removing an epic takes a single value, and once the call goes through, Taiga no longer holds that epic.

Key parameters

Epic ID: the identifier of the epic to delete, usually carried in from an earlier node as {{ $json.id }} rather than typed by hand.

Use cases

a workflow that creates epics from an external backlog needs a matching cleanup branch. When the source record is cancelled, the same run deletes the epic it opened, and the board does not fill up with shells nobody wants to touch.

03

Get an epic

epic.get

What you see in n8n

Notes & use cases

Reading one epic returns its current state as Taiga stores it, which is what an IF node needs before it decides anything.

Key parameters

Epic ID: the identifier of the epic to retrieve. The node returns that epic only, so this is the call for a targeted lookup rather than a scan.

Use cases

before a progress update goes out to a client, the workflow fetches the epic and checks whether it is still blocked. Nobody announces movement on work that is on hold, and the check costs one node.

04

Get many epics

epic.getAll

What you see in n8n

Notes & use cases

One call brings back the epics of a project, one n8n item per epic, ready to loop over.

Key parameters

Project Name or ID: required, and it scopes the whole call to a single project.
Return All: on, n8n walks every page of epics; off, Limit sets the maximum number of epics returned.
Is Closed: in Filters, keeps closed epics in or out of the result.

Use cases

a monthly roadmap export runs with Return All on and Is Closed off, so the file only shows what is still live.

05

Update an epic

epic.update

What you see in n8n

Notes & use cases

Epics change as a quarter goes on. This operation rewrites the fields you provide and leaves everything else as it was.

Key parameters

Epic ID: the identifier of the epic to update.
Is Blocked: in Update Fields, the toggle that marks the epic as blocked.
Blocked Note: the reason for the block. It needs the Is Blocked toggle enabled to mean anything, so set the two together.

Use cases

a dependency slips upstream, and the workflow flags the epic with the reason written out, so the next stand-up starts from the board instead of from memory.

Issue

5 operations

06

Create an issue

issue.create

What you see in n8n

Notes & use cases

Issues are the bug and incident side of Taiga. This operation files one in a project and hands back the created issue.

Key parameters

Project Name or ID and Subject: the two required fields, the destination project and the issue title.
Priority Name or ID, Severity Name or ID and Type Name or ID: in Additional Fields, the three qualifiers that let a triage workflow set the shape of the issue at creation time.

Use cases

an inbound report is classified upstream, and the severity it earns is written straight into the issue instead of being fixed by hand later.

07

Delete an issue

issue.delete

What you see in n8n

Notes & use cases

Sometimes a workflow has to undo its own work, and this operation erases an issue from the project.

Key parameters

Issue ID: the identifier of the issue to delete. Feed it from the node that found the issue, so the deletion targets the record you actually inspected.

Use cases

a deduplication step compares a new report against the open queue. When two entries describe the same bug, the newer one goes and the original keeps the history, the comments and the assignee it already had.

08

Get an issue

issue.get

What you see in n8n

Notes & use cases

When a workflow needs the live state of one issue, this is the call. It returns the issue as it stands right now, not as it looked when an event fired.

Key parameters

Issue ID: the identifier of the issue to retrieve, often taken from a trigger payload.

Use cases

a chat alert that only says an issue moved is useless. Placing this operation right after the trigger lets the message carry the subject, the status and the person on it, which is what the reader wants.

09

Get many issues

issue.getAll

What you see in n8n

Notes & use cases

A project accumulates issues fast, so this operation comes with the richest filter set of the four listings.

Key parameters

Project Name or ID: required, and the scope of the query.
Order By: in Filters, sorts the result, for instance on created_date or on severity.
Return All: on for a complete export, off to stop at Limit.

Use cases

a morning triage list pulls open issues ordered by created_date, so the oldest untouched report is the first thing the team reads.

10

Update an issue

issue.update

What you see in n8n

Notes & use cases

Everything about an issue can move after it is filed, and this operation is where those changes are applied.

Key parameters

Issue ID: the identifier of the issue to update, the only required field.
Status Name or ID: in Update Fields, the new status of the issue.
Milestone (Sprint) Name or ID: the milestone the issue belongs to, which is how a workflow pulls a bug into the running sprint.

Use cases

a customer confirms a fix, and the issue closes and joins the current sprint in one run, without anyone reopening the board.

Task

5 operations

11

Create a task

task.create

What you see in n8n

Notes & use cases

Tasks sit under a user story in Taiga. This operation adds one to a project and returns it.

Key parameters

Project Name or ID and Subject: required, the project and the task title.
User Story Name or ID: in Additional Fields, the story the task hangs under, which is what keeps the taskboard readable.
Taskboard Order: the position of the task on the taskboard.

Use cases

a recurring checklist is expanded into tasks under the story that carries the work, each one placed in the order the team performs it.

12

Delete a task

task.delete

What you see in n8n

Notes & use cases

Clearing a task out of the board is a one-field operation, and it is final on the Taiga side.

Key parameters

Task ID: the identifier of the task to delete. Route it through a filter first, because there is no confirmation step once the node runs.

Use cases

a checklist generated automatically turns out not to apply, the scope changes, and the workflow removes the tasks it created earlier in the same batch so the story keeps only the work that is still real.

13

Get a task

task.get

What you see in n8n

Notes & use cases

Pulling one task back into a workflow returns every field Taiga holds for it, in a single item.

Key parameters

Task ID: the identifier of the task to retrieve.

Use cases

a time tracking flow receives a task reference from an external tool and needs the subject and the status before it writes anything. This operation resolves the reference, and the row that ends up in the spreadsheet reads like a sentence instead of a number.

14

Get many tasks

task.getAll

What you see in n8n

Notes & use cases

Task lists get long, so this listing ships with its own filter set, aimed at the taskboard rather than the backlog.

Key parameters

Project Name or ID: required.
User Story Name or ID: in Filters, narrows the result to the tasks of one story.
Is Closed: keeps or drops the tasks already finished.
Return All: on to page through the whole list, off to stop at Limit.

Use cases

a daily count of open tasks per story feeds a simple burn-down without anyone touching a spreadsheet.

15

Update a task

task.update

What you see in n8n

Notes & use cases

Moving a task forward, or sideways, goes through this operation. Only the fields you fill are written.

Key parameters

Task ID: the identifier of the task to update.
Status Name or ID: in Update Fields, the new status of the task.
User Story Order: the position of the task inside its user story, handy when the sequence matters more than the status.

Use cases

a developer closes a task from a chat command, and the workflow writes the status back to Taiga so the board matches reality before the stand-up.

User Story

5 operations

16

Create a user story

userStory.create

What you see in n8n

Notes & use cases

User stories carry the work in Taiga. This operation adds one to a project and returns the created story.

Key parameters

Project Name or ID and Subject: the two required fields.
Backlog Order: in Additional Fields, the position of the story in the backlog, so a new arrival can land at the top instead of the bottom.
Milestone (Sprint) Name or ID: the sprint the story belongs to, when it is already planned.

Use cases

notes from a discovery interview become stories, ordered by the priority the interviewer gave them.

17

Delete a user story

userStory.delete

What you see in n8n

Notes & use cases

Some stories should never have existed. This operation removes one from the project for good.

Key parameters

User Story ID: the identifier of the story to delete, which the node expects as an identifier and not as the title you see on the board.

Use cases

a workflow under test has written a dozen stories into a real project. A cleanup run reads the identifiers it logged during the test and deletes them one by one, leaving the backlog as it was before.

18

Get a user story

userStory.get

What you see in n8n

Notes & use cases

A single story, fetched by identifier, comes back with the fields Taiga keeps on it, including its status and its ordering values.

Key parameters

User Story ID: the identifier of the story to retrieve.

Use cases

a release note is being drafted from a list of shipped references. For each one, this operation supplies the subject and the description, so the note is written from the board rather than from what somebody remembers of the sprint.

19

Get many user stories

userStory.getAll

What you see in n8n

Notes & use cases

Story listings are where reporting usually starts, and the filters here follow the way a backlog is organised.

Key parameters

Project Name or ID: required.
Epic Name or ID: in Filters, returns only the stories attached to one epic.
Is Archived: keeps archived stories in or out.
Return All: on for the full backlog, off to stop at Limit.

Use cases

an epic progress report counts the stories of that epic by status, archived ones excluded, and sends the ratio to the product owner.

20

Update a user story

userStory.update

What you see in n8n

Notes & use cases

Rewriting a story after the fact is what this operation is for, whether the change is a status or a position on a board.

Key parameters

User Story ID: the identifier of the story to update.
Status Name or ID: in Update Fields, the new status.
Kanban Order and Sprint Order: the position of the story in the kanban and in the milestone, the two values that decide where it appears.

Use cases

an approval arrives from outside the team, and the story moves to the next column at the right rank.

Need help

Need help automating Taiga with n8n?

A person reads every message.

FAQ

Taiga and n8n, the questions that come next

01Is the Taiga n8n integration free?

Yes, on the n8n side. The Taiga node and the Taiga Trigger ship with n8n, so there is nothing to install and nothing extra to pay, whether you work on n8n Cloud or on a self-hosted instance under the Community Edition and its Sustainable Use licence. A workflow behaves the same in both cases. What you do need is a Taiga account, since the credential authenticates as a real user of that account. What Taiga itself costs is outside the scope of this page.

02What credentials does the Taiga node need?

Basic auth, and nothing more complicated. The credential asks for a Username, which accepts either your username or the email address on the account, and a Password. It also asks for an Environment, Cloud or Self-Hosted, and when you pick Self-Hosted a URL field appears for the address of your own instance. One credential serves both the Taiga node and the Taiga Trigger, and once it is saved in the Credentials menu it shows up in the dropdown of every workflow that needs it.

03What are the limits of the Taiga node in n8n?

Two of them matter in practice. The first is pagination: on Get many epics, issues, tasks and user stories, Return All is what makes n8n go through every page, and with it switched off the Limit value caps the result. The second is coverage: the node exposes 20 operations across 4 resources, and anything the Taiga API offers beyond that list is reached with the HTTP Request node, which reuses the same Taiga credential through predefined authentication. So a missing endpoint costs you one extra node, not a separate login.

04Does the Taiga Trigger react in real time?

Yes. The Taiga Trigger works by webhook, meaning n8n registers a URL that Taiga calls when something happens, and the event reaches your workflow within seconds. There is no polling and no interval to set. The webhook is registered when you activate the workflow, so a workflow left inactive receives nothing. You choose what arrives with the Operations parameter, which offers 6 values, and there is no wildcard character to type: select the all value to receive every event type.

05n8n or Make for Taiga?

It depends on four things, and price alone is not one of them. Hosting: n8n runs on your own server with Docker or npm, or on n8n Cloud, while Make is hosted only. Data control follows from that, since a self-hosted instance keeps Taiga payloads inside your infrastructure. Cost model: Make bills per operation, which changes how you design a workflow that loops over a long backlog. And visual logic, where the two tools simply feel different. Try the same small Taiga workflow on both and the answer usually becomes obvious.

Create the Taiga credential

Pick the right environment

Select the credential in the node

Every event, by family

Configuration notes

Need help automating Taiga with n8n?