Splunk n8n integrationAutomate Splunk with n8n.

Splunk keeps a record of the alerts that have fired, and this operation retrieves that report into the workflow. There is nothing to fill in: choose the Alert resource, run the node, and the report arrives as items the following nodes can read.

Metrics sit under the same Alert resource and also come back with a single call, no fields to complete. The operation retrieves metrics from the instance and hands them to the workflow as regular items.

A search job that produced something worth keeping can become a saved search report. That is what this operation creates, from an existing job rather than from a query typed again.

• Search Job: the job the report is built from, required, picked in the node's list or supplied as an ID from an earlier step with an expression such as {{ $json.field }}.
• Name: optional, the name of the report. Set it and the report is findable later by a human.

Saved reports accumulate, especially the ones a workflow created. This operation removes one from Splunk, and it takes nothing beyond the report itself, which makes it the closing node of a cleanup branch rather than a workflow of its own.

• Report: the report to remove, required, selected in the node or identified by ID through an expression.

Reading one saved report back into a workflow is the job here. Splunk returns that single report, and every node downstream works on what came back.

• Report: which report to retrieve, required, chosen in the node's list or passed as an ID, for instance {{ $json.field }} when a previous node decided which one.

Listing the saved search reports gives a workflow something to iterate over, which is where most cleanup and audit logic starts.

• Return All: on, n8n walks the API pages and brings back every report; off, it stops at Limit.
• Limit: the maximum number of reports returned while Return All is off.
• Add Orphan Field: adds a boolean to each saved search showing whether it is orphaned, meaning it has no valid owner.

Everything else in the Search resource depends on this one: the operation submits a query and creates the search job that runs it on the instance.

• Query: required, the search language string to execute, written in Splunk's Search Processing Language. The node shows the expected shape, search index=_internal | stats count by source.
• Earliest Time and Latest Time: in Additional Fields, the earliest and latest cut-off for the search, both inclusive.
• Max Time: seconds to run before finalizing. Enter 0 to never finalize.

Jobs stay on the instance once they have run. Removing them is what this operation does, and an automated workflow that runs every hour is exactly the kind that would otherwise leave a long trail behind it.

• Search Job: required, the job to delete, chosen in the node or carried from the step that created it.

This operation retrieves a single search job and returns it to the workflow, without asking for the rows it produced. It is the step you put between creating a job and requesting its result.

• Search Job: required, the job to retrieve, selected in the node or referenced by ID through an expression.

Rather than one job by ID, this returns many of them at once, which is how you get a view of what is sitting on the instance.

• Return All: brings back every search job by paging through the API; left off, the node stops at Limit.
• Limit: how many jobs come back when Return All is off.

Results are the reason the search was run. This operation gets them from a job and turns them into items the rest of the workflow can route, filter and write somewhere else.

• Search Job: required, the job whose result you want, usually the one created upstream and referenced with an expression like {{ $json.field }}.
• Return All and Limit: all rows, or the first batch up to Limit.
• Key-Value Match: a key-value pair to match against. Key set to user and Field set to john returns only the results where user is john.
• Add Summary to Metadata: includes field summary statistics in the response.

Opening a Splunk account from a workflow means this operation, which creates the user on the instance with the roles it needs on day one.

• Name: required, the login name of the user.
• Roles: required, the roles to assign, chosen from the list or specified as IDs through an expression.
• Password: required.
• Email and Full Name: in Additional Fields, the address and the full name of the user.

Offboarding ends with the account itself, and this operation removes it from Splunk. One field, no options, which is deliberate for an irreversible step.

• User: required, the account to remove, picked in the node or passed as an ID from the step that identified the leaver.

One account, one lookup. The operation retrieves a single user from Splunk and returns it, which is enough for a workflow that has to check something about a person before acting.

• User: required, the account to retrieve, selected in the node or referenced by ID with an expression.

Who has access to the instance is a question that comes up every audit, and this operation answers it by returning many users in one run.

• Return All: every account on the instance, page after page; off, the node returns the first ones only.
• Limit: the ceiling on accounts returned when Return All stays off. On an access review, leaving it in place is how you end up with a partial list and a false sense of a clean audit.

People move teams and roles follow, which this operation handles: it updates an existing account rather than replacing it.

• User: required, the account being updated.
• Role Names or IDs: in Update Fields, the roles to assign, from the list or as IDs through an expression.
• Email, Full Name, Password: the other Update Fields, each applied only when filled in.