Resources · n8n integration

MISP n8n integrationAutomate MISP with n8n.

Can a workflow drive a MISP instance end to end? It can. The MISP n8n integration exposes 44 operations across 11 resources: events, attributes, event tags, feeds and more. There is no MISP trigger node, so a Schedule Trigger or a webhook opens the run.

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the MISP n8n integration actually give you?

It puts a MISP instance behind a workflow instead of behind a browser tab. n8n ships a MISP node that talks to the MISP API with an automation key, and it exposes 44 operations spread over 11 resources: events, attributes, event tags, feeds, galaxies, noticelists, objects, organisations, tags, users and warninglists. Nothing to install, on n8n Cloud or on a self-hosted instance.

Take the first scenario, documenting something that just came in. A Schedule Trigger picks up the item, event.create opens a MISP event under the organization you choose, then attribute.create attaches the value to that event with a Type of url, text or comment. One run, one documented event, no copying between tabs.

Reporting is the second win. event.getAll with Return All switched on walks the pages of the API and hands every event to the next node, which can be Google Sheets for a weekly summary, or Postgres when the history has to be queried months later. attribute.search does the same on a narrower slice, filtered by Tags or Category.

Third, the review that happens before an event goes out. event.update adjusts Analysis and Threat Level ID while an analyst works, eventTag.add stamps the agreed tag, and event.publish closes the loop. A message to Slack at that moment tells the team the event is published.

The node covers 44 operations across 11 resources. When a workflow needs an endpoint outside that catalog, the HTTP Request node calls it directly and reuses the same credential through predefined authentication, so the automation key never gets stored twice.

Two things shape how you design these workflows. There is no MISP trigger node, so every run starts from a Schedule Trigger at a fixed interval, from an n8n Webhook (a URL another service calls), or from another tool's trigger. And any list operation stops at Limit until Return All is enabled. If you are still weighing platforms before committing, the n8n review takes the hosting question apart.

Connect

How do you connect MISP to n8n?

  1. 01

    Generate an automation key in MISP

    In MISP, API keys are called automation keys. Open Event Actions > Automation and copy the key sitting there. MISP's automation keys documentation covers how to generate more of them, which is worth doing if you would rather give each workflow its own key than share one across the whole instance.

  2. 02

    Create the MISP credential in n8n

    Open the Credentials menu in n8n and add a MISP credential. Two fields carry the connection: API Key, the automation key you just copied, and Base URL, the address of your MISP instance. A credential is created once and then reused by every workflow, and the node offers it in a dropdown instead of asking you to paste the key again.

  3. 03

    Pick a resource and an operation

    Drop the MISP node into a workflow, select the credential, then choose a resource and an operation, Event and Publish for instance. Required fields are not decorative: leave one empty and the node stops the execution. Values that come from an earlier node go in as expressions, written {{ $json.field }}, which is how n8n reads a field off the incoming item.

Actions

What can the MISP node do?

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

Resources × operations matrix
ResourceCreateGetGet ManyUpdateDeleteAddRemoveDisableEnablePublishSearchUnpublish
Attribute✓✓✓✓✓✓
Event✓✓✓✓✓✓✓✓
Event Tag✓✓
Feed✓✓✓✓✓✓
Galaxy✓✓✓
Noticelist✓✓
Object✓
Organisation✓✓✓✓✓
Tag✓✓✓✓
User✓✓✓✓✓
Warninglist✓✓

Attribute

6 operations
01

Create an attribute

attribute.create

What you see in n8n

Notes & use cases

New values land in MISP as attributes, and this call creates one inside an event you already identified.

Key parameters

  • Event UUID: the UUID of the event the attribute gets attached to, often {{ $json.field }} from the node that created the event.
  • Type: three choices, text, url and comment.
  • Value: required, so the node halts the execution while it stays empty.
  • Distribution: an additional field that decides who will be able to see this event once published.
Use cases
enriching an event opened earlier in the same workflow, one attribute per item coming out of a loop.
02

Delete an attribute

attribute.delete

What you see in n8n

Notes & use cases

Removal is the whole job here: the attribute disappears from the event it was attached to.

Key parameters

  • Attribute ID: the UUID or the numeric ID of the attribute, both accepted.
Use cases
cleaning up after a bad import, where a search operation earlier in the workflow collects the attributes to drop and this node runs once per item. Worth pairing with a manual approval step, since nothing here asks for confirmation.
03

Get an attribute

attribute.get

What you see in n8n

Notes & use cases

Reading one attribute back gives the following nodes its full record rather than the identifier alone.

Key parameters

  • Attribute ID: the UUID or numeric ID of the attribute you want.
Use cases
a workflow that receives an attribute reference from a ticketing tool and needs the stored record before deciding anything. Also handy as a check step after an update, confirming that what MISP holds matches what the workflow sent.
04

Get many attributes

attribute.getAll

What you see in n8n

Notes & use cases

Listing attributes without a filter returns them in a batch, one n8n item per attribute.

Key parameters

  • Return All: switched on, n8n chains the pages of the API until every attribute is in; switched off, it stops at Limit.
  • Limit: the maximum number of attributes returned when Return All stays off.
Use cases
a nightly export of the attribute base into a spreadsheet or a database, where Return All is the difference between a full dump and a truncated one.
06

Update an attribute

attribute.update

What you see in n8n

Notes & use cases

Editing an existing attribute happens through this operation, which leaves the fields you do not fill untouched.

Key parameters

  • Attribute ID: the ID of the attribute to update.
  • Distribution: an update field for who will be able to see this event once published.
  • Sharing Group Name or ID: only useful when Sharing Group is the value selected in Distribution, chosen from the list or given as an expression.
Use cases
widening or tightening visibility on a batch of attributes once a case moves to another team.

Event

8 operations
07

Create an event

event.create

What you see in n8n

Notes & use cases

Every MISP event starts somewhere, and this operation opens a new one under an organization you select.

Key parameters

  • Organization Name or ID: picked from the list, or given as an expression when the value comes from an earlier node.
  • Information: the description of the event, up to 65535 characters.
  • Threat Level ID: High, Medium, Low or Undefined.
  • Analysis: the analysis maturity level, Initial, Ongoing or Complete.
Use cases
opening one event per incoming report, then attaching attributes to it in the same run.
08

Delete an event

event.delete

What you see in n8n

Notes & use cases

Deleting an event takes it out of the instance, and the attributes attached to it go with the event.

Key parameters

  • Event ID: the UUID or numeric ID of the event.
Use cases
tearing down test events after a workflow has been validated on a staging instance, so the trial runs do not stay in the base. Put an IF node in front of it that checks the event actually belongs to the test organization.
09

Get an event

event.get

What you see in n8n

Notes & use cases

Pulling one event back by its identifier hands the rest of the workflow the full record to work from.

Key parameters

  • Event ID: the UUID or numeric ID of the event, accepted in either form.
Use cases
a chat command. Someone drops an event reference and the workflow answers with what MISP holds. It also fits between two writes, reading the event back before deciding whether the second one is still needed at all.
10

Get many events

event.getAll

What you see in n8n

Notes & use cases

Bulk reading is what this call is for: MISP returns the events, and n8n turns each one into a separate item.

Key parameters

  • Return All: on, n8n follows the pages until the whole list is retrieved; off, it stops early.
  • Limit: the ceiling on how many events come back while Return All is off.
Use cases
a weekly recap that counts the events opened over the period and posts the figure to a channel.
11

Publish an event

event.publish

What you see in n8n

Notes & use cases

Publishing moves an event into its published state, the point from which its distribution setting decides who sees it.

Key parameters

  • Event ID: the UUID or numeric ID of the event to publish.
Use cases
the last step of a review workflow, where a human approval in n8n gates the call so nothing goes out automatically. Sending a Slack message right after it gives the team a readable trace of what got published and when.
13

Unpublish an event

event.unpublish

What you see in n8n

Notes & use cases

The reverse move: the event leaves its published state and goes back to being an internal record.

Key parameters

  • Event ID: the UUID or numeric ID of the event.
Use cases
a correction path. Someone flags a mistake in a ticket, the workflow unpublishes the event, updates it, and only republishes after a second pair of eyes. Chaining it with an approval node keeps the rollback deliberate rather than automatic.
14

Update an event

event.update

What you see in n8n

Notes & use cases

Editing an event after the fact goes through here, field by field, without touching what you leave blank.

Key parameters

  • Event ID: the UUID or numeric ID of the event to change.
  • Information: the description, up to 65535 characters.
  • Analysis: Initial, Ongoing or Complete.
  • Distribution: who will be able to see this event once published.
Use cases
moving Analysis from Ongoing to Complete when the linked ticket closes, with the description rewritten in the same call.

Event Tag

2 operations
15

Add a tag to an event

eventTag.add

What you see in n8n

Notes & use cases

Tags are how events stay findable later, and this call attaches one to an event that already exists.

Key parameters

  • Event ID: the UUID or numeric ID of the event receiving the tag.
  • Tag Name or ID: chosen from the list, or given as an expression when the tag depends on the incoming item.
Use cases
tagging every event created from a given source in the same run, so a later search on Tags rebuilds that batch in one step.
16

Remove a tag from an event

eventTag.remove

What you see in n8n

Notes & use cases

Detaching a tag leaves the event itself alone, only the link between the two disappears.

Key parameters

  • Event ID: the UUID or numeric ID of the event.
  • Tag Name or ID: the tag to detach, from the list or as an expression.
Use cases
retiring a temporary tag once a case is closed. A search that lists everything carrying the tag, then this node running once per item, clears the whole set without opening MISP.

Feed

6 operations
17

Create a feed

feed.create

What you see in n8n

Notes & use cases

A feed is registered in MISP with a name, a provider and a URL, and this operation writes that registration.

Key parameters

  • Name: required text.
  • Provider: required text.
  • URL: required, in the shape of https://example.com.
  • Rules: an additional field holding the filter rules for the feed.
Use cases
registering feeds from a list held elsewhere, so the same set can be rebuilt on a second instance without anyone retyping the URLs.
18

Disable a feed

feed.disable

What you see in n8n

Notes & use cases

Turning a feed off is a single call, and the registration stays in place for later.

Key parameters

  • Feed ID: the UUID or numeric ID of the feed.
Use cases
a source that has gone noisy or unreachable. A workflow that notices the problem elsewhere can disable the feed straight away and warn the team, which beats waiting for someone to spot it in the interface.
19

Enable a feed

feed.enable

What you see in n8n

Notes & use cases

Switching a feed back on takes the same shape, with the identifier as the only thing to provide.

Key parameters

  • Feed ID: the UUID or numeric ID of the feed to enable.
Use cases
the second half of a maintenance window. One scheduled workflow disables the feeds before the operation, another enables them afterwards, and the list of identifiers lives in a spreadsheet rather than in someone's memory.
20

Get a feed

feed.get

What you see in n8n

Notes & use cases

One feed, read by its identifier, with its registration returned to the next node.

Key parameters

  • Feed ID: the UUID or numeric ID of the feed.
Use cases
a check step before an update, so the workflow knows what is currently registered before overwriting anything. It is also the quickest way to answer a question from a colleague about what a given feed points at.
21

Get many feeds

feed.getAll

What you see in n8n

Notes & use cases

The full inventory of feeds comes back here, one n8n item per feed.

Key parameters

  • Return All: on, every feed is retrieved page after page; off, the run stops at Limit.
  • Limit: how many feeds at most come back while Return All is off.
Use cases
an audit of the sources registered on the instance, exported into a table so the team can review what is still worth keeping.
22

Update a feed

feed.update

What you see in n8n

Notes & use cases

Changing a registration without deleting it is what this operation is for.

Key parameters

  • Feed ID: the ID of the feed to update.
  • URL: the address the feed points at.
  • Provider: the provider recorded for the feed.
  • Rules: the filter rules for the feed.
Use cases
a provider moves its file to a new address and a workflow rewrites the URL on every affected feed, instead of someone editing them one by one.

Galaxy

3 operations
23

Delete a galaxy

galaxy.delete

What you see in n8n

Notes & use cases

Removing a galaxy is a one shot call: the node sends a single identifier and MISP drops that galaxy from the instance the credential points to.

Key parameters

  • Galaxy ID: the UUID or the numeric ID of the galaxy to delete. When the value arrives from an earlier node, reference it with an expression, the n8n syntax that reads a field of the incoming item, written {{ $json.field }}.
Use cases
a cleanup workflow reads a review sheet and, for every approved row, deletes the matching galaxy by Galaxy ID.
24

Get a galaxy

galaxy.get

What you see in n8n

Notes & use cases

Point the node at one galaxy and it returns that record on its own, so a workflow never has to walk the whole instance to find it.

Key parameters

  • Galaxy ID: the UUID or the numeric ID of the galaxy to read.
Use cases
an internal request form drops a galaxy identifier into the workflow, the node reads the record, and the branch that follows decides whether anything else needs to happen.
25

Get many galaxies

galaxy.getAll

What you see in n8n

Notes & use cases

Listing galaxies hands the workflow the inventory the instance holds, which is the usual first step before anything gets filtered or compared further down.

Key parameters

  • Return All: switched on, n8n keeps requesting pages until every galaxy has come back; switched off, the node stops at Limit.
  • Limit: the maximum number of galaxies returned while Return All stays off.
Use cases
a scheduled run lists galaxies with Return All on and stores the output, so the next run can show what moved.

Noticelist

2 operations
26

Get a noticelist

noticelist.get

What you see in n8n

Notes & use cases

A single noticelist comes back when the node is given its number, without touching the rest of the catalog. That keeps the output small enough to read in one look when the run is being debugged.

Key parameters

  • Noticelist ID: the numeric ID of the noticelist to fetch, hardcoded when the workflow always reads the same one, or taken from the incoming item with an expression written {{ $json.field }}.
Use cases
a workflow started from an analyst message fetches the noticelist quoted in that message and forwards the content to the formatting step.
27

Get many noticelists

noticelist.getAll

What you see in n8n

Notes & use cases

Pulling the full set of noticelists gives a workflow the view of everything that catalog carries at a given moment.

Key parameters

  • Return All: on, the node walks through the API pages until nothing is left; off, it hands back only what Limit allows.
  • Limit: caps how many noticelists the node returns.
Use cases
a nightly job lists noticelists and writes them into a database table, so changes stay visible over time.

Object

1 operation

Organisation

5 operations
29

Create an organization

organisation.create

What you see in n8n

Notes & use cases

Creating an organization writes a new entry in MISP under the name the node sends.

Key parameters

  • Name: required, the organization name, and the only value the operation needs to run.
  • Additional Fields: the optional block that carries Description, Sector, Nationality, Type, Created by Email and User Count in the same call.
Use cases
a partner joins a sharing group, and an approval workflow creates the organization with its Name while filling Sector from the request form.
30

Delete an organization

organisation.delete

What you see in n8n

Notes & use cases

Once an organization no longer belongs on the instance, this operation removes its record in a single call. Since nothing in the node asks for a confirmation, the safety net belongs in the workflow itself.

Key parameters

  • Organisation ID: the UUID or the numeric ID of the organisation to remove, which is why a read step usually runs first to confirm the right record was picked.
Use cases
a decommissioning workflow takes the identifier from a ticket and deletes the organization once a manual approval node has passed.
31

Get an organization

organisation.get

What you see in n8n

Notes & use cases

Reading one organization record is all this does: the node returns the entry matching the identifier it was given, and nothing around it.

Key parameters

  • Organisation ID: the UUID or the numeric ID of the organisation to read, mapped from the preceding node with an expression such as {{ $json.field }}.
Use cases
before an account is set up, a workflow reads the organization named in the request and routes the run on what comes back.
32

Get many organizations

organisation.getAll

What you see in n8n

Notes & use cases

The full roster of organizations known to the instance comes back here, one item per organization.

Key parameters

  • Return All: enabled, n8n chains the API pages until every organization sits in the output; disabled, Limit decides how many come back.
  • Limit: the ceiling on the number of organizations returned.
Use cases
a monthly review lists organizations with Return All enabled and compares the output against the internal directory.
33

Update an organization

organisation.update

What you see in n8n

Notes & use cases

Editing an existing organization means naming it by ID, then listing what should change in the Update Fields block.

Key parameters

  • Organisation ID: required, the ID of the organisation to update.
  • Update Fields: the block that carries Name, Description, Sector, Nationality and Type.
Use cases
a partner rebrands, and a workflow updates the organization Name from an approved form entry rather than through the MISP interface.

Tag

4 operations
34

Create a tag

tag.create

What you see in n8n

Notes & use cases

Tags are created from a name, and the node can give the new tag its color in the same call.

Key parameters

  • Name: required, the tag name.
  • Color: a hex color code for the tag, inside Additional Fields.
Use cases
a workflow that opens a new sharing exercise creates the tags it needs up front, each with its own Color so analysts read them at a glance.
35

Delete a tag

tag.delete

What you see in n8n

Notes & use cases

When a tag stops being used, this operation removes it from the instance by number.

Key parameters

  • Tag ID: required, the numeric ID of the tag to delete, often taken from an earlier node with an expression such as {{ $json.field }}.
Use cases
a housekeeping workflow lists the tags, filters the ones flagged in an internal sheet, and deletes them one by one.
36

Get many tags

tag.getAll

What you see in n8n

Notes & use cases

Every tag defined on the instance comes back through this operation, the list most other tag work starts from.

Key parameters

  • Return All: on, the node pages through the API until the tag list is complete; off, Limit sets the cutoff.
  • Limit: the maximum number of tags in the output.
Use cases
a workflow lists tags ahead of a bulk job, so the names it is about to use are checked against what already exists.
37

Update a tag

tag.update

What you see in n8n

Notes & use cases

Renaming a tag or changing its color runs through this operation, with the tag named by its ID.

Key parameters

  • Tag ID: required, the ID of the tag to update.
  • Update Fields: carries Name and Color, the hex color code of the tag.
Use cases
a naming convention changes, so a workflow walks the tag list and rewrites each Name into the new format.

User

5 operations
38

Create a user

user.create

What you see in n8n

Notes & use cases

Onboarding an account takes two values, an address and a role, and the node creates the user from them.

Key parameters

  • Email: required, the address of the account, in the name@email.com form the field shows.
  • Role ID: required, and role IDs are available in the MISP dashboard at /roles/index.
  • Organization Name or ID: chosen from the list the node loads, or given as an ID through an expression.
Use cases
a joiner workflow reads the HR request and creates the account with the Role ID mapped to the job title.
39

Delete a user

user.delete

What you see in n8n

Notes & use cases

Offboarding ends here: the node removes the user whose number it is given, and the workflow moves on to whatever comes next.

Key parameters

  • User ID: required, the numeric ID of the user to delete. A run that leaves it empty stops there, since an empty required field blocks the node.
Use cases
when a leaver is marked in the internal directory, the workflow deletes the matching account and writes the run into a log table, so the access review has a trail to follow later.
40

Get a user

user.get

What you see in n8n

Notes & use cases

One user record, fetched by number, lands in the output of this operation. It reads a single account, so it pairs well with a loop when several have to be checked.

Key parameters

  • User ID: required, the numeric ID of the user to read, usually mapped from the item the previous node produced with an expression such as {{ $json.field }}.
Use cases
an access review workflow reads each account in turn and keeps every response for the report it assembles at the end of the run.
41

Get many users

user.getAll

What you see in n8n

Notes & use cases

This operation walks the user directory of the instance and returns the accounts it finds.

Key parameters

  • Return All: on, every page of users is fetched; off, Limit caps the number of accounts returned.
  • Limit: how many users at most come back in one run.
Use cases
a quarterly access review lists users with Return All enabled and compares the output with the HR roster before anything is changed.
42

Update a user

user.update

What you see in n8n

Notes & use cases

Changes to an existing account travel through Update Fields, with the account named by its ID.

Key parameters

  • User ID: required, the ID of the user to update.
  • Update Fields: carries Email, GPG Key, Inviter Name or ID and Organization Name or ID.
Use cases
an analyst moves to another team, and a workflow updates the Organization Name or ID on the account without anyone opening MISP.

Warninglist

2 operations
43

Get a warninglist

warninglist.get

What you see in n8n

Notes & use cases

Warninglists are read one at a time here, by number, which keeps the payload down when only one of them matters to the run.

Key parameters

  • Warninglist ID: required, the numeric ID of the warninglist. When the number comes from an earlier step rather than being typed in, an expression like {{ $json.field }} carries it over.
Use cases
a triage workflow reads the warninglist referenced in an internal note and passes the content to the step that formats the summary.
44

Get many warninglists

warninglist.getAll

What you see in n8n

Notes & use cases

The catalog of warninglists the instance carries comes back in one run.

Key parameters

  • Return All: on, n8n requests page after page until the catalog is complete; off, Limit trims the output.
  • Limit: the maximum number of warninglists returned.
Use cases
an audit workflow lists warninglists and stores the result, so the following run can show what was added since.
Need help

Need help automating MISP with n8n?

A person reads every message.

FAQ

MISP and n8n, the questions that come up

01Is the MISP n8n integration free?
On the n8n side, yes. The MISP node ships with n8n, so there is nothing to install and no extra cost, whether you work on n8n Cloud or on a self-hosted instance under the Community Edition and its Sustainable Use license. The 44 operations are all available the moment the credential connects. MISP itself is a separate question: the credential expects an instance that you install and run, and what that instance costs you in hosting and maintenance sits outside n8n entirely. A workflow behaves the same way on both setups, so nothing has to be rewritten if you move from one to the other later.
02What credentials does the MISP node need?
One credential, built on an API key. In MISP these keys are called automation keys, and you get one from Event Actions > Automation; MISP's documentation explains how to generate more of them if you prefer one key per workflow. The credential asks for that API Key and for a Base URL, which is the address of your own MISP instance. A third setting, Allow Unauthorized Certificates, lets n8n connect even when SSL certificate validation fails, which matters on instances behind a self-signed certificate. You create the credential once in the Credentials menu and every workflow picks it from a dropdown.
03What are the limits of the MISP node in n8n?
The node exposes 44 operations spread over 11 resources, so the catalog is wide but finite. When a workflow needs an endpoint that is not in it, the HTTP Request node calls that endpoint directly against the MISP API and reuses the same credential through predefined authentication, which keeps the automation key in one place. The other thing to plan for is pagination: any list operation stops at Limit until Return All is switched on, and forgetting that switch is how an export ends up quietly truncated. Required fields are strict too, an empty one stops the execution rather than sending a partial call.
04Does the MISP node react in real time?
There is no MISP trigger node in n8n, so nothing on the MISP side pushes events into a workflow. A run starts from something else: a Schedule Trigger firing at a fixed interval, an n8n Webhook, meaning a URL that another service calls when something happens on its end, or the trigger of another tool already in the chain. In practice, a scheduled run paired with event.search or attribute.search covers most of what a trigger would have done, since the search operations filter on the MISP side and return only what changed against the criteria you set.
05n8n or Make for MISP?
The honest answer depends on where your data can live. n8n runs on your own servers through Docker or npm, or on n8n Cloud, and the same workflow behaves identically on both. Make is hosted only, with no self-hosting option, and it bills per operation. For a MISP instance, which is usually installed and run in house, the ability to keep the automation on the same side of the network as the instance often settles the question on its own. Cost models differ too, per operation on one side against your own hosting on the other, and the visual logic is a matter of habit more than capability.