Resources · n8n integration

Currents n8n integrationAutomate Currents with n8n.

Your test suite already knows which specs waste the most time. The Currents n8n integration turns that knowledge into workflows: 22 operations across 8 resources covering runs, tests, spec files and actions, plus a trigger that listens to 4 run events and fires within seconds.

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What can the Currents n8n integration actually do?

Currents collects the results of your test runs. n8n is the workflow engine that reacts to them. Put together, the Currents node gives a workflow 22 operations spread over 8 resources: runs, tests, spec files, test results, projects, project insights, actions and signatures. The Currents Trigger adds 4 run events, delivered by webhook, which is an URL that Currents calls as soon as something happens.

The first thing teams build is an alert that nobody has to watch for. The trigger listens on RUN_FINISH, a Get a run step pulls the full record, and a message lands in Slack with the branch and the status. No dashboard to refresh, no tab left open during a deploy window.

The second one is flaky test triage, and it is where the node earns its place. Get many tests returns aggregated metrics for a project over a date window, ordered by flakiness. Feed the worst offender into Generate a signature, which turns a spec file path and a test title into the stable identifier Currents uses for that test. Hand that signature to Create an action with an action type of quarantine, and the test stops breaking builds while somebody fixes it. Set an expiry date on the action so the quarantine does not become permanent by accident.

The third one saves compute. When a pull request gets three pushes in five minutes, the earlier runs are already useless. Cancel a run by GitHub CI takes the GitHub Actions run ID and attempt number straight from the CI payload, so the workflow cancels the right run without ever looking up a Currents identifier.

Reporting sits one step further out. Get project insights and Get many spec files both work over a date range and both accept branch, tag and git author filters, which makes them a clean source for a weekly recap written into Google Sheets or an Airtable base that the whole team can sort.

Anything the Currents API offers beyond these 22 catalogued operations is reachable with the HTTP Request node, which calls any endpoint while reusing the same credential through predefined authentication. That is the normal escape hatch in n8n, not a workaround.

If you are weighing the platform itself before you commit a quality pipeline to it, the n8n review covers hosting and cost, and the n8n training goes through expressions and error handling, the two things that decide whether a test automation workflow survives its first bad week.

Connect

How do you connect Currents to n8n?

  1. 01

    Create the credential once

    In n8n, open the Credentials menu and add a Currents credential. A credential is created once and reused by every workflow on the instance, so the token never gets pasted into a node by hand. The exact fields are the ones the credential form shows when you open it; fill them, save, and the credential becomes available to both the Currents node and the Currents Trigger.

  2. 02

    Pick it in the node

    Drop a Currents node on the canvas. Its credential dropdown lists the credentials already saved on the instance, so select the one you just created. The same list appears on the Currents Trigger, which means one credential covers both the reading side and the listening side of your workflows. n8n Cloud and a self-hosted instance behave identically here.

  3. 03

    Prove it works on a read

    Set the resource to Project and the operation to Get many projects, then execute the node. It takes no required parameter, so a successful run means the credential is valid and nothing else. From that output you get the project identifiers that the Project resource locator expects on most other operations, either picked from the list or passed as an expression such as {{ $json.field }}.

Triggers

What starts a workflow from Currents ?

Currents Trigger is the node that starts a workflow when something happens in Currents. It listens to 4 events, listed below by family. Pick one or several, activate the workflow: n8n registers the webhook on your Currents 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.

RUN_CANCELED.*1
  • RUN_CANCELED.
    • RUN_CANCELED
RUN_FINISH.*1
  • RUN_FINISH.
    • RUN_FINISH
RUN_START.*1
  • RUN_START.
    • RUN_START
RUN_TIMEOUT.*1
  • RUN_TIMEOUT.
    • RUN_TIMEOUT

Configuration notes

01Configure the Currents TriggerThe trigger comes in version 1 and works on events, meaning you choose which run events should wake the workflow up rather than setting a schedule.

The trigger comes in version 1 and works on events, meaning you choose which run events should wake the workflow up rather than setting a schedule.

Key parameters

  • Project: a required resource locator that scopes the trigger to one Currents project, picked from the list or given by identifier. Events from other projects never reach this workflow.
  • Events: the list of run events to subscribe to. There is no catch-all option on this trigger, so each event you want has to be ticked explicitly, and adding one later means editing and reactivating the workflow.
When to use it
whenever the workflow should react to a run rather than go looking for one. Currents calls the n8n webhook URL, an address registered at activation, and the event lands in seconds without polling.
02Run StartedRUN_START fires when a new run begins. It is the earliest signal Currents sends, which makes it the one to use for anything that has to be in place before results exist.

RUN_START fires when a new run begins. It is the earliest signal Currents sends, which makes it the one to use for anything that has to be in place before results exist.

Use cases
a build channel that gets a single line when a nightly suite starts, so a silent night becomes visible immediately. Or a bookkeeping workflow that records the start time, then waits for the matching finish event to compute how long the suite really took, branch by branch.
When to use it
only when something downstream genuinely needs the start, because on a busy repository this event fires on every push. The Project parameter already scopes that volume to a single project, which removes a good part of it before you write any filter, and the finish event on its own keeps a workflow much quieter.
03Run FinishedRUN_FINISH fires when a run completes. By then Currents holds the full picture of the run, which is why most workflows hang everything off this single event.

RUN_FINISH fires when a run completes. By then Currents holds the full picture of the run, which is why most workflows hang everything off this single event.

Use cases
pull the run with Get a run and route on its status, so a passing run stays silent and a failing one opens a thread with the branch name. The same event is the natural hook for a nightly digest: collect the finished runs, then write one row per run instead of one message per failure.
When to use it
for reporting, notification and anything that needs results rather than intent. Pair it with the cancel and timeout events if the workflow must also account for runs that never reached a clean end.
04Run Canceled and Run TimeoutTwo events cover the runs that end without a verdict. RUN_CANCELED fires when someone cancels a run manually, and RUN_TIMEOUT fires when a run exceeds its time limit.

Two events cover the runs that end without a verdict. RUN_CANCELED fires when someone cancels a run manually, and RUN_TIMEOUT fires when a run exceeds its time limit.

Use cases
a timeout usually points at infrastructure rather than code, so route RUN_TIMEOUT to whoever owns the CI machines, with the run identifier attached. A cancellation is often deliberate, so a quiet log entry is enough there, and comparing the two counts over a week tells you whether the suite is getting slower or the team is getting impatient.
When to use it
together with the finish event, when a report is supposed to reconcile every run that started. Both are ticked in Events like any other, and both stay inside the project set on the trigger, so a shared n8n instance can watch one repository without hearing about the rest.
Actions

What can the Currents node do in a workflow?

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

Resources × operations matrix
ResourceCreateGetGet ManyUpdateDeleteCancelCancel by GitHub CIDisableEnableFindGenerateGet InsightsReset
Action
Instance
Project
Run
Signature
Spec File
Test
Test Result

Action

7 operations
01

Create an action

action.create

What you see in n8n

Notes & use cases

Quarantine, skip and tag rules live in Currents as actions, and this operation creates one from a workflow instead of from the interface.

Key parameters

  • Name: the label of the rule, between 1 and 255 characters.
  • Action Type: quarantine, skip or tag, which decides what happens to the matching tests.
  • Matcher Type and Matcher Value: how the rule finds its tests, by spec file path, by test title or by signature, and the value to match.
  • Expires After: an ISO 8601 date after which the rule stops applying.
Use cases
quarantine a test that has failed on three consecutive nightly runs, with an expiry date two weeks out so the rule cannot be forgotten.
02

Delete an action

action.delete

What you see in n8n

Notes & use cases

Archiving is the soft way out. The rule stops applying and stays on record rather than vanishing from the project history.

Key parameters

  • Action ID: the identifier of the action to archive, usually carried over from Get many actions in the same workflow.
Use cases
a monthly cleanup that lists the actions of a project, keeps the ones still tied to an open ticket and archives the rest, so the rule set stays readable for whoever joins the team next quarter.
03

Disable an action

action.disable

What you see in n8n

Notes & use cases

Sometimes a rule needs a pause rather than an ending. Disabling deactivates an active action and leaves it ready to come back.

Key parameters

  • Action ID: the identifier of the action to deactivate.
Use cases
before a release candidate goes through a full regression pass, switch off the quarantine rules so the suite runs exactly as it would in production conditions, and the report shows the real failure count rather than a filtered one.
04

Enable an action

action.enable

What you see in n8n

Notes & use cases

Bringing a paused rule back is a single call, and it is the other half of any workflow that disables one.

Key parameters

  • Action ID: the identifier of the disabled action to reactivate.
Use cases
the tail end of a release workflow, where the quarantine rules turned off for the regression pass get switched back on once the candidate is signed off, so the next feature branch is not slowed down by known flaky tests.
05

Get an action

action.get

What you see in n8n

Notes & use cases

Before touching a rule, read it. This operation returns one action by identifier, which is what lets a workflow decide instead of guess.

Key parameters

  • Action ID: the identifier of the action to read.
Use cases
a branch in a maintenance workflow that reads the action referenced in a ticket, checks its expiry date and only then decides whether to extend it with Update an action or to archive it. Reading first also keeps the workflow safe to re-run.
06

Get many actions

action.getAll

What you see in n8n

Notes & use cases

Auditing what a project currently enforces starts here, with the list of its actions.

Key parameters

  • Project: the resource locator that scopes the list to one project.
  • Search: matches actions by name, up to 100 characters.
  • Status: keeps only the states you tick, among active, archived, disabled and expired.
Use cases
a weekly digest of every active quarantine rule, so a test that was parked for a sprint does not quietly stay parked for a quarter.
07

Update an action

action.update

What you see in n8n

Notes & use cases

Renaming a rule or pushing back its expiry date happens in place, without recreating the action and losing its identifier.

Key parameters

  • Action ID: the identifier of the action to change.
  • Name, Description and Expires After: the three update fields, sent only when you add them, so an update that touches the date leaves the name alone.
Use cases
extend a quarantine by one sprint and write the ticket reference into the description at the same time.

Instance

1 operation
08

Get an instance

instance.get

What you see in n8n

Notes & use cases

An instance is one spec file execution inside a run, and this operation returns it with the full test results attached.

Key parameters

  • Instance ID: the identifier of the spec file execution instance to read.
Use cases
when a failure notification names a spec file, this is the call that turns the name into the detail, so the message posted to the team contains the failing test titles instead of a link that somebody has to open.

Project

3 operations
09

Get a project

project.get

What you see in n8n

Notes & use cases

Reading a single project record gives a workflow the context around the numbers it is about to handle.

Key parameters

  • Project: the resource locator, picked from the list or given by identifier.
Use cases
a report generator that starts by reading the project so the document carries a real project name rather than a raw identifier, which matters as soon as a summary leaves the engineering team and goes to someone who never opens Currents.
10

Get many projects

project.getAll

What you see in n8n

Notes & use cases

Listing every project is how a lot of Currents workflows begin, since it needs no input at all.

Key parameters

  • Limit: the maximum number of projects returned, useful when the workflow only needs a handful for a lookup.
Use cases
a scheduled workflow that loops over every project and builds one insights report per project, so a new repository is covered the day it is created and nobody has to remember to add it.
11

Get project insights

project.getInsights

What you see in n8n

Notes & use cases

Metrics over a date window rather than a single run, which is the view that shows a trend.

Key parameters

  • Project, Date Start and Date End: all three required, the dates in ISO 8601 format.
  • Resolution: 1h, 1d or 1w, the granularity of the series.
  • Branches, Tags, Groups and Git Authors: comma separated filters to narrow the window.
Use cases
a Monday morning recap at 1d resolution on the main branch only.

Run

7 operations
12

Cancel a run

run.cancel

What you see in n8n

Notes & use cases

Stopping a run in progress takes one identifier and nothing else.

Key parameters

  • Run ID: the identifier of the run to cancel, typically the one a previous step already found.
Use cases
a workflow watching a long lived branch that cancels the run in progress when a revert is pushed, because the results about to arrive describe code that no longer exists. Cancelling explicitly also produces a clean cancel event rather than a timeout later on.
13

Cancel a run by GitHub CI

run.cancelGithub

What you see in n8n

Notes & use cases

GitHub Actions has its own identifiers. This operation takes them as is, with no Currents-side lookup.

Key parameters

  • GitHub Run ID and GitHub Run Attempt: both required, taken from the Actions workflow run and its attempt number.
  • Project ID and CI Build ID: optional narrowing, when the same GitHub run feeds more than one project or build.
Use cases
a webhook fired from a cancelled Actions job that closes the matching Currents run in the same breath.
14

Delete a run

run.delete

What you see in n8n

Notes & use cases

Deletion here is final, and it takes the data associated with the run along with it.

Key parameters

  • Run ID: the identifier of the run to delete.
Use cases
cleaning up the runs produced by a misconfigured CI job that reported against the wrong project, where leaving them in place would skew every flakiness metric afterwards. Worth guarding with a manual approval step, since nothing here is reversible.
15

Find a run

run.find

What you see in n8n

Notes & use cases

Finding a run without knowing its identifier is exactly what this operation is for.

Key parameters

  • Project: the resource locator that scopes the search.
  • Branch, CI Build ID and Tags: the filters that identify the run you mean, by git branch name, by CI build or by tag.
Use cases
a chat command where somebody types a branch name and the workflow answers with the state of the run that belongs to it.
16

Get a run

run.get

What you see in n8n

Notes & use cases

Once a run identifier is in hand, this returns the run itself, and it is the step that sits right behind most trigger events.

Key parameters

  • Run ID: the identifier of the run to read.
Use cases
the second node of a notification workflow, between the trigger and the message, so the alert carries the branch and the outcome instead of only saying that something finished somewhere.
17

Get many runs

run.getAll

What you see in n8n

Notes & use cases

Reporting workflows lean on this one, because it is the only operation that reads a whole stretch of run history at once.

Key parameters

  • Project: required, and Limit caps how many runs come back.
  • Status and Completion State: two different axes, one on PASSED or FAILED, the other on COMPLETE, CANCELED, TIMEOUT or IN_PROGRESS.
  • Starting After and Ending Before: cursors taken from a previous response to page through a long history.
  • Tags with Tag Operator: AND demands every tag, OR accepts any.
Use cases
a weekly export of every failed run on the release branch.
18

Reset a run

run.reset

What you see in n8n

Notes & use cases

Failed specs simply get replayed, so nobody has to restart the whole suite from scratch just to recheck a handful of tests.

Key parameters

  • Run ID: the run whose failed specs should be replayed.
  • Machine IDs: a comma separated list of machine identifiers, from 1 to 63 of them, which decides how the replay is spread.
  • Batched Orchestration: an option that switches the replay to batched orchestration.
Use cases
an automatic single retry after a timeout, so an infrastructure hiccup does not turn into a red build that someone has to re-run by hand.

Signature

1 operation
19

Generate a signature

signature.generate

What you see in n8n

Notes & use cases

A signature identifies one test across every run it ever appeared in, and this operation builds it.

Key parameters

  • Project: the resource locator the test belongs to.
  • Spec File Path: the complete path to the spec file.
  • Test Title: the title of the test, with nested describe blocks joined by the separator > .
Use cases
the bridge between a failure and its history, since the signature produced here is what Get test results and a signature based action both expect.

Spec File

1 operation
20

Get many spec files

specFile.getAll

What you see in n8n

Notes & use cases

Aggregated metrics per spec file answer a blunt question: which files cost the most time.

Key parameters

  • Project, Date Start and Date End: the required window, dates in ISO 8601 format.
  • Order By with Sort Direction: rank on avgDuration, failureRate, flakeRate or timeoutRate, ascending or descending.
  • Include Failed in Duration: decides whether failed executions count towards the duration.
  • Page: page number, counted from 0.
Use cases
a monthly list of the slowest spec files to split.

Test

1 operation
21

Get many tests

test.getAll

What you see in n8n

Notes & use cases

Same idea one level down, at the test rather than the file, which is where flakiness actually lives.

Key parameters

  • Project, Date Start and Date End: the required window.
  • Order By: flakiness, failures, duration and the impact variants that weigh a rate by its sample count.
  • Minimum Executions: drops tests that ran too rarely for their rate to mean anything.
  • Test State: keeps only failed, passed, pending or skipped.
Use cases
the flaky top ten that opens the weekly quality review.

Test Result

1 operation
22

Get test results

testResult.getAll

What you see in n8n

Notes & use cases

History for a single test, run after run, which is the view that settles an argument about whether something is broken or merely unlucky.

Key parameters

  • Test Signature: required, and produced by Generate a signature from the project, spec file path and test title.
  • Date Start and Date End: the required window, in ISO 8601 format.
  • Status and Branches: narrow the history to the outcomes and branches that matter.
Use cases
proving a test only fails on one branch before anybody rewrites it.
Need help

Need help automating Currents with n8n?

A person reads every message.

FAQ

Currents and n8n, the questions that come next

01Is the Currents n8n integration free?
Yes on the n8n side. The Currents node and the Currents Trigger ship with n8n, so there is nothing to install and nothing extra to pay for, on n8n Cloud as well as on a self-hosted instance running the Community Edition under the Sustainable Use licence. A workflow built on one runs identically on the other, which means you can prototype on Cloud and move the same JSON to your own Docker install later. What a Currents account itself costs is a separate question and depends on your plan there, so check that with Currents directly.
02What credentials do you need to connect Currents to n8n?
One Currents credential, created once in the Credentials menu of your n8n instance. Both the Currents node and the Currents Trigger read from that same entry, so a single credential covers the 22 operations and the 4 trigger events. Once saved, it appears in the credential dropdown of every Currents node you add, and the token is never pasted into a workflow by hand. The node itself has no authentication selector, so there is no method to choose. Test the credential with a read that takes no parameter, Get many projects, before you build anything on top of it.
03What are the limits of the Currents node in n8n?
Two things are worth planning for. Pagination first: the list operations take a Limit, and Get many runs and Get test results expose Starting After and Ending Before cursors that you feed from a previous response, while Get many spec files and Get many tests page with a Page number starting at 0. A long history therefore needs a loop, not a single call. Second, anything the Currents API offers beyond these 22 catalogued operations goes through the HTTP Request node, which reaches any endpoint and reuses the same credential through predefined authentication.
04Does the Currents Trigger react in real time?
Yes. The trigger works by webhook, an URL that Currents calls as soon as something happens, so events arrive within seconds and n8n never polls for them. n8n registers that URL with Currents when you activate the workflow, which is also why a workflow left in draft receives nothing. The trigger is scoped to one project through its Project parameter and to the events you tick in Events. There is no catch-all option, so each of the 4 events you care about has to be selected explicitly, and adding one afterwards means reactivating the workflow.
05n8n or Make for Currents?
It comes down to hosting and cost model. Make is hosted by Make, with no self-hosting option, and bills per operation, which is predictable but grows with volume. n8n runs on Cloud or on your own server through Docker or npm, and a workflow is identical either way, so test data that you would rather keep inside your own network can stay there. The Currents node covers the same 22 operations in both cases. If your automation mostly reads run metrics on a schedule, either platform will do the job; if it sits inside a CI pipeline you already self-host, keeping the two together tends to win.
Hack'celeration Lab

Get our weekly integration tips.

No spam. Unsubscribe anytime.