- Home
- Resources
- Integrations
- Currents
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
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.
How do you connect Currents to n8n?
- 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.
- 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.
- 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 }}.
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.*1RUN_CANCELED. RUN_CANCELED
RUN_FINISH.*1RUN_FINISH. RUN_FINISH
RUN_START.*1RUN_START. RUN_START
RUN_TIMEOUT.*1RUN_TIMEOUT. RUN_TIMEOUT
Configuration notes
01Configure the Currents Trigger
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.
02Run Started
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.
03Run Finished
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.
04Run Canceled and Run Timeout
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.
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.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.
| Resource | Create | Get | Get Many | Update | Delete | Cancel | Cancel by GitHub CI | Disable | Enable | Find | Generate | Get Insights | Reset |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Action | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Instance | ✓ | ||||||||||||
| Project | ✓ | ✓ | ✓ | ||||||||||
| Run | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Signature | ✓ | ||||||||||||
| Spec File | ✓ | ||||||||||||
| Test | ✓ | ||||||||||||
| Test Result | ✓ |
Operations index
Action
7 operationsCreate an action
action.createWhat 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,skiportag, 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.
Delete an action
action.deleteWhat 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.
Disable an action
action.disableWhat 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.
Enable an action
action.enableWhat 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.
Get an action
action.getWhat 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.
Get many actions
action.getAllWhat 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,disabledandexpired.
active quarantine rule, so a test that was parked for a sprint does not quietly stay parked for a quarter.Update an action
action.updateWhat 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.
Instance
1 operationGet an instance
instance.getWhat 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.
Project
3 operationsGet a project
project.getWhat 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.
Get many projects
project.getAllWhat 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.
Get project insights
project.getInsightsWhat 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,1dor1w, the granularity of the series. - Branches, Tags, Groups and Git Authors: comma separated filters to narrow the window.
1d resolution on the main branch only.Run
7 operationsCancel a run
run.cancelWhat 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.
Cancel a run by GitHub CI
run.cancelGithubWhat 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.
Delete a run
run.deleteWhat 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.
Find a run
run.findWhat 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.
Get a run
run.getWhat 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.
Get many runs
run.getAllWhat 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
PASSEDorFAILED, the other onCOMPLETE,CANCELED,TIMEOUTorIN_PROGRESS. - Starting After and Ending Before: cursors taken from a previous response to page through a long history.
- Tags with Tag Operator:
ANDdemands every tag,ORaccepts any.
Reset a run
run.resetWhat 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.
Signature
1 operationGenerate a signature
signature.generateWhat 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
>.
Spec File
1 operationGet many spec files
specFile.getAllWhat 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,flakeRateortimeoutRate, ascending or descending. - Include Failed in Duration: decides whether failed executions count towards the duration.
- Page: page number, counted from
0.
Test
1 operationGet many tests
test.getAllWhat 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,durationand 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,pendingorskipped.
Test Result
1 operationGet test results
testResult.getAllWhat 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.
Need help automating Currents with n8n?
A person reads every message.
Currents and n8n, the questions that come next
01Is the Currents n8n integration free?
02What credentials do you need to connect Currents to n8n?
03What are the limits of the Currents node in n8n?
04Does the Currents Trigger react in real time?
05n8n or Make for Currents?
Get our weekly integration tips.
No spam. Unsubscribe anytime.



