Recursos · Integración n8n

Integración Cortex n8nAutomatiza Cortex con n8n.

Un análisis que se queda en la cola es una alerta que nadie mira. La integración Cortex n8n trae 4 operaciones repartidas en 3 recursos: Analyzer, Responder y Job. No existe ningún trigger de Cortex, así que el flujo arranca desde un horario o desde otra herramienta, y luego lanza el análisis y recoge el informe.

Reseñas verificadas en Trustpilot · Agencia de IA, automatización y growth

Por qué automatizar

¿Qué resuelve la integración Cortex n8n?

El nodo Cortex aplica un analizador o un responder a una entidad concreta, en un servidor Cortex que alojas tú. El analizador recibe un observable, o sea el valor que quieres comprobar, y devuelve un veredicto. El responder recibe una entidad y actúa sobre ella. En ambos casos el servidor crea un job, y el nodo puede volver a leer ese job y su informe más tarde.

El primer escenario es el que más tiempo devuelve: ningún valor se comprueba ya a mano. Un Schedule Trigger, el disparador que se activa cada cierto intervalo, saca los documentos pendientes de MongoDB, el nodo pasa cada uno por analyzer.execute y el veredicto llega a un canal de Slack junto al valor analizado. El analista abre el canal, no la consola.

El segundo escenario empieza donde termina el primero: la respuesta no espera al turno de mañana. Cuando vuelve el veredicto, un nodo IF manda los casos malos a responder.execute, que entrega la entidad al responder elegido. La entidad viaja como JSON, así que lo que la generó antes en el flujo se reutiliza tal cual.

El tercero cierra el círculo: un histórico que se puede consultar. Los jobs terminan en el servidor y job.report devuelve el informe a partir del identificador del job. Guárdalo en Google Sheets y dentro de unos meses sabrás qué se comprobó y con qué resultado sin abrir Cortex. Hay una plantilla pública, 1602, que combina el nodo Cortex con el nodo TheHive para analizar correos, y otra, 809, dedicada solo a recuperar los detalles de un job.

Los límites se cuentan rápido. El nodo cubre analizadores, responders y jobs, y nada más de la API de Cortex. Para el resto está el nodo HTTP Request, que llama a cualquier endpoint reutilizando el mismo credential, es decir el acceso que guardas una vez en n8n. Tampoco hay trigger de Cortex, así que el flujo siempre arranca en otro sitio.

Si la duda es sobre la plataforma y no sobre el nodo, la Reseña n8n entra en el alojamiento y el coste, y el Curso n8n practica expresiones y control de errores sobre flujos reales.

Conexión

¿Cómo conectas Cortex con n8n?

  1. 01

    Instala Cortex en tu servidor

    Cortex es software que ejecutas tú, así que el primer paso ocurre fuera de n8n. Instálalo en una máquina que tu instancia de n8n pueda alcanzar por red y apunta la dirección en la que responde. Esa dirección es la que pide después el credential, con el formato http://<your_server_address>:9001/ que el campo muestra por defecto.

  2. 02

    Genera una clave API en Cortex

    La autenticación va con una clave API, y solo con eso. Se genera desde el propio Cortex, para la cuenta cuyos analizadores y responders va a usar el flujo: cada job se ejecuta con los permisos ligados a esa clave. Copia el valor en ese momento y déjalo fuera del flujo. Su sitio es el credential, nunca un campo del nodo.

  3. 03

    Crea el credential de Cortex en n8n

    En n8n, abre el menú Credentials y crea un credential de Cortex, el acceso que n8n guarda para autenticarse. La clave va en API Key y la dirección del servidor en Cortex Instance. Un credential se crea una sola vez y aparece luego en el desplegable de cualquier nodo Cortex, así que el segundo flujo ya no configura nada.

Acciones

¿Qué sabe hacer el nodo Cortex ?

El nodo Cortex expone 4 operaciones en 3 recursos. Para cada una: el nodo tal como lo configuras en n8n, los campos obligatorios y nuestras notas de campo.

Matriz recursos × operaciones
RecursoGetExecuteReport
Analyzer✓
Job✓✓
Responder✓

Analyzer

1 operación
01

Execute an analyzer

analyzer.execute

Lo que ves en n8n

Notas y casos de uso

Lanza un analizador sobre un observable y devuelve el job que Cortex acaba de crear.

Parámetros clave

  • Analyzer Type Name or ID: se elige en la lista que carga el nodo desde tu servidor, o con una expresión como {{ $json.analyzer }}.
  • Observable Type Name or ID: el tipo del valor que envías, en otra lista igual.
  • Observable Value: el valor en sí.
  • Put Output File in Field: el nombre del campo binario de salida del archivo.
  • TLP: el nivel de difusión del observable analizado, de 0 (White) a 3 (Red).
  • Force: salta la caché cuando un valor ya se analizó y quieres repetirlo.
Casos de uso
comprobar cada valor de una cola antes de que lo vea una persona.

Job

2 operaciones
02

Get a job

job.get

Lo que ves en n8n

Notas y casos de uso

Devuelve los detalles que Cortex guarda de un job, a partir de su identificador.

Parámetros clave

  • Job ID: el identificador del job, casi siempre {{ $json.id }} heredado del nodo que lo lanzó.
Casos de uso
el bucle de espera sobre un analizador lento. El flujo arranca el job, un nodo Wait hace pausa, esta operación relee el job y un IF decide si toca otra vuelta o seguir. De las dos operaciones de Job es la ligera: cuenta en qué punto está el trabajo, no lo que ha encontrado.
03

Get a job report

job.report

Lo que ves en n8n

Notas y casos de uso

Recupera lo que ha producido el analizador o el responder, ya con el job terminado.

Parámetros clave

  • Job ID: el mismo identificador, usado después del final del job y no durante.
Casos de uso
el archivo. El informe es la parte que merece guardarse, así que suele acabar en una base de datos o en una hoja de cálculo, o se extrae un campo suelto para redactar un mensaje corto. Pedido demasiado pronto en un análisis largo, no trae nada aprovechable: para eso está el bucle Wait anterior.

Responder

1 operación
04

Execute a responder

responder.execute

Lo que ves en n8n

Notas y casos de uso

Entrega una entidad a un responder para que Cortex actúe sobre ella, en vez de limitarse a describirla.

Parámetros clave

  • Responder Type Name or ID: qué responder ejecutar, desde la lista o con una expresión.
  • Entity Type Name or ID: el tipo de dato del objeto que envías.
  • Entity Object (JSON): el objeto mismo, en JSON.
  • JSON Parameters: alterna entre un único objeto JSON y atributos separados, que se rellenan en Parameters.
Casos de uso
el paso siguiente a un veredicto negativo, donde la entidad que salió del análisis entra en la respuesta sin que nadie la vuelva a teclear.
Necesitas ayuda

¿Necesitas ayuda para automatizar Cortex con n8n?

El equipo te responde directamente.

Cada mensaje lo lee una persona.

FAQ

Cortex y n8n, las dudas que llegan después

01¿La integración Cortex n8n es gratuita en n8n?
Sí, por el lado de n8n. El nodo Cortex viene incluido con n8n: no hay nada que instalar ni ningún módulo que comprar, y se comporta igual en n8n Cloud, la oferta alojada por n8n, que en una instancia propia levantada con Docker o con npm. Un flujo hecho en una funciona sin cambios en la otra. Lo que hay al otro lado del credential es otro asunto: Cortex es software que instalas en tu propio servidor, y ese es el requisito previo para que el nodo tenga con quién hablar. El coste de esa parte no se trata aquí.
02¿Qué credenciales hacen falta para conectar Cortex con n8n?
Una clave API y la dirección de tu servidor. Cortex admite autenticación por clave API y nada más, así que no hay OAuth que negociar ni lista de permisos que repasar. El formulario del credential pide dos datos: la clave y la URL de la instancia de Cortex, un campo que llega relleno con una plantilla que apunta al puerto 9001 de tu propio servidor. Los dos viven en un único credential guardado en el menú Credentials de n8n, y cualquier nodo Cortex lo encuentra luego en su desplegable. El alcance es el de la cuenta detrás de la clave: una clave con pocos permisos limita qué analizadores y responders puede lanzar el flujo.
03¿Qué límites tiene el nodo Cortex?
Es un nodo corto a propósito. Cubre 4 operaciones sobre 3 recursos: ejecutar un analizador, ejecutar un responder, leer un job y leer el informe de un job. El resto de la API de Cortex no tiene operación propia, y la salida es el nodo HTTP Request, que llama a cualquier endpoint reutilizando el mismo credential mediante la autenticación predefinida. Tampoco hay nodo trigger, de modo que nada del lado de Cortex puede arrancar un flujo por su cuenta. Y como los analizadores trabajan en forma de job y no con respuesta inmediata, un análisis largo pide esperar antes de pedir el informe.
04¿Puede un flujo reaccionar a un job de Cortex al instante?
Desde Cortex no, porque no existe el nodo trigger de Cortex. Un flujo que lo use arranca siempre en otro punto, y con tres montajes se cubre casi todo. El Schedule Trigger se activa cada cierto intervalo y procesa lo que está pendiente. El nodo Webhook le da a n8n una URL, una dirección que un servicio externo llama cuando ocurre algo, así que la herramienta que detecta el observable lo empuja directamente. O bien el trigger de otra herramienta abre la cadena y el nodo Cortex queda más abajo. Con el job ya lanzado, las operaciones de Job dicen en qué punto está.
05¿n8n o Make para Cortex?
Depende de por dónde pueden pasar los datos. Cortex corre en tu servidor y n8n puede correr al lado, autoalojado con Docker o npm, de forma que los observables no salen de una infraestructura que controlas. Make está alojado, sin opción de autoalojamiento, y factura por operación, algo que pesa cuando un flujo analiza muchos valores uno a uno. A cambio, su editor visual se lee antes para quien no monta automatizaciones cada semana. Resumiendo: Make para un flujo alojado y con pocas operaciones, n8n cuando el análisis debe quedarse en casa o el volumen encarece el pago por operación.