Nodo Webhook n8nConfigura Webhook en n8n.

De serie, un webhook escucha un solo método: GET o POST, nunca los dos. Activar este booleano en los ajustes del nodo levanta esa restricción, y el nodo pasa a tener una salida por método para ramificar según cómo lo hayan llamado.

• Allow Multiple HTTP Methods: desactivado de inicio; ya activo, el nodo acepta GET y POST, y los demás se añaden en el campo HTTP Method.
• HTTP Method: los métodos que se escuchan, entre DELETE, GET, HEAD, PATCH, POST, PUT.

Es el final de la URL del webhook. n8n la rellena con una cadena aleatoria para que dos nodos no choquen, algo prudente pero imposible de dictar por teléfono. Cámbiala por algo legible en cuanto la URL tenga que escribirse en la configuración de un tercero.

• Path: un campo de texto, ejemplo webhook, que admite variables de ruta escritas con dos puntos: /:variable, /path/:variable, /:variable/path, /:variable1/path/:variable2 o /:variable1/:variable2. En cuanto hay un valor dinámico, n8n antepone webhookId a la ruta.

Nada impide que un desconocido llame a una URL de webhook abierta. Este selector coloca un control delante del flujo, y la llamada que no lo supera jamás llega al primer nodo.

• Authentication: basicAuth para un par de usuario y contraseña, headerAuth para un secreto compartido enviado en la cabecera que elijas, jwtAuth para emisores que ya mandan un token firmado, none para una dirección pública.

Fija cuándo recibe su respuesta quien llama y qué lleva dentro. Separa al simple receptor del punto de entrada donde el emisor espera de verdad.

• Respond: onReceived contesta nada más ejecutarse el nodo, con el mensaje Workflow got started; lastNode devuelve los datos del último nodo ejecutado; responseNode cede la respuesta a un nodo Respond to Webhook situado más adelante.
• Response Data: con lastNode, elige allEntries para un array, firstEntryJson para un objeto único, firstEntryBinary para un archivo o noData para un cuerpo vacío.
• Property Name: obligatorio con firstEntryBinary, nombra la propiedad binaria que se devuelve.

Las peticiones entrantes se leen como JSON salvo que se indique otra cosa. Este interruptor hace que el nodo acepte un archivo dentro de la petición, justo lo que necesitas el día que un proveedor manda un PDF en vez de un enlace al PDF.

• Binary File: un booleano que declara que el webhook va a recibir datos binarios. Solo aparece con los métodos POST, PATCH o PUT.

Un archivo recibido tiene que quedar guardado en algún campo del item para que los nodos siguientes lo encuentren. Esa es toda la función de esta opción, y solo cuenta si de verdad llegan datos binarios.

• Field Name for Binary Data: el nombre del campo de salida donde se escribe el archivo recibido.

Pega una URL de webhook en una herramienta de chat y su previsualizador la visitará al instante. El flujo arranca, aparece una ejecución y nadie la ha pedido. Esta opción descarta a esos visitantes antes de que se dispare nada.

• Ignore Bots: un booleano que ignora las peticiones de bots como los previsualizadores de enlaces y los rastreadores web.

La autenticación mira un secreto; esta opción mira la dirección. Tiene sentido cuando quien llama es un servidor fijo y no un navegador: entonces la lista de orígenes legítimos es corta y se conoce de antemano.

• IP(s) Allowlist: una lista de direcciones o rangos CIDR separados por comas, ejemplo e.g. 127.0.0.1, 192.168.1.0/24. Vacía, deja pasar todas las direcciones.

Hay emisores que solo leen un código de estado y otros a los que un cuerpo inesperado les molesta. Con este ajuste activo, la respuesta sale sin cuerpo alguno.

• No Response Body: un booleano que impide que n8n envíe cuerpo en la respuesta. Está disponible con Respond en onReceived.

La respuesta lleva por defecto todo el JSON de la entrada. Señalar aquí una propiedad la reduce a ese único valor, algo que agradecen los emisores que esperan una cadena y no un objeto.

• Property Name: el nombre de la propiedad cuyo valor se devuelve en lugar del JSON completo. Aparece con Respond en lastNode y Response Data en firstEntryJson.

Con este ajuste puesto, el nodo conserva el cuerpo tal como llegó en vez de analizarlo. Todo lo que el análisis habría reformado, o rechazado, pasa intacto.

• Raw Body: un booleano que indica que el nodo recibe el cuerpo en formato crudo, en binario.

Una ejecución correcta responde con un código por defecto. Se cambia cuando quien llama lee el estado para decidir el siguiente paso, algo habitual con proveedores que reintentan en cuanto ven un código que no esperaban.

• Response Code: a elegir entre 200, 201, 204, 301, 302, 304, 400, 401, 403, 404 o customCode.
• Code: el número que se devuelve con customCode, ejemplo e.g. 400.

Las respuestas salen como application/json. Este campo sustituye esa cabecera cuando el receptor espera otro formato, y solo cambia el tipo anunciado, nunca los datos.

• Response Content-Type: un content-type propio que se devuelve en lugar de application/json, ejemplo application/xml. Aparece con Respond en lastNode y Response Data en firstEntryJson.

En vez de devolver lo que ha producido el flujo, este ajuste manda una cadena fija. La respuesta se decide al diseñar y no depende de la ejecución.

• Response Data: el texto propio que se envía, ejemplo success. Disponible con Respond en onReceived.

Añade cabeceras a lo que el nodo devuelve. Cada entrada es un nombre y un valor, y puedes apilar tantas como pida el receptor.

• Name: el nombre de la cabecera.
• Value: su valor, que admite una expresión como {{ $json.token }} cuando tiene que salir del flujo.