Webhook Filter

Coloca este nodo justo después de un Webhook o FormTrigger para actuar como puerta de seguridad y validación antes de que el resto del flujo se ejecute.

Descripción

Webhook Filter verifica dos cosas en secuencia:

1. Método HTTP — ¿Está el método de la petición entre los que habilitaste?
2. Campos requeridos — ¿Contiene el payload todos los campos que declaraste como obligatorios?

Si alguna verificación falla, el flujo se detiene y el cliente recibe el código HTTP y el body de error que configuraste. Si ambas pasan, los datos continúan sin modificación al siguiente nodo.

Configuración

Campo	Tipo	Requerido	Descripción
Permitir GET	Boolean	No	Acepta peticiones GET. Por defecto: false
Permitir POST	Boolean	No	Acepta peticiones POST. Por defecto: true
Permitir PUT	Boolean	No	Acepta peticiones PUT. Por defecto: false
Permitir DELETE	Boolean	No	Acepta peticiones DELETE. Por defecto: false
Permitir PATCH	Boolean	No	Acepta peticiones PATCH. Por defecto: false
Permitir OPTIONS	Boolean	No	Acepta peticiones OPTIONS. Por defecto: false
Campos requeridos en el payload	JSON	No	Array de rutas de campos que deben existir en el payload. Soporta notación punto. Ejemplo: ["email", "user.name"]
Código de error HTTP	Select	No	Código devuelto cuando falla la validación: 400, 401, 403, 404, 405, 422, 429 o 500. Por defecto: 400
Cuerpo de la respuesta de error	JSON	No	JSON personalizado enviado como body del error. Si está vacío, se genera un mensaje automático.

:::tip Métodos por defecto Si ningún método está habilitado, el filtro deja pasar todos los métodos. Esto permite usar el nodo únicamente para validación de campos sin restringir verbos. :::

Cómo funciona

Formato de respuesta de error

Cuando una verificación falla, el flujo termina y devuelve una respuesta HTTP directamente al cliente:

HTTP 400 Bad Request

{
  "error": true,
  "message": "Required field 'email' is missing or empty"
}

Si configuras un Cuerpo de error personalizado, tu JSON reemplaza completamente el mensaje automático.

Ejemplos de uso

Ejemplo 1 — Aceptar solo POST con campos requeridos

{
  "label": "Webhook Filter",
  "allowPOST": true,
  "requiredFields": ["email", "order.id", "order.total"],
  "errorCode": "422",
  "errorBody": {
    "success": false,
    "message": "Petición inválida. Faltan campos requeridos."
  }
}

Comportamiento:

• Una petición GET → devuelve HTTP 422 inmediatamente
• Un POST sin email → devuelve HTTP 422 con el body personalizado
• Un POST con todos los campos → continúa al siguiente nodo

Ejemplo 2 — Solo validación de campos (sin restricción de método)

{
  "label": "Webhook Filter",
  "requiredFields": ["token", "payload"],
  "errorCode": "401",
  "errorBody": { "error": "No autorizado" }
}

Como ningún método está habilitado, todos los verbos HTTP son permitidos y solo se verifica la presencia de campos.

Ejemplo 3 — Gateway de API REST (GET + POST)

{
  "label": "Webhook Filter",
  "allowGET": true,
  "allowPOST": true,
  "errorCode": "405",
  "errorBody": { "error": "Método no permitido" }
}

Notación punto para campos anidados

El array requiredFields soporta rutas anidadas con notación punto:

Ruta	Verifica
"email"	payload.email
"user.name"	payload.user.name
"order.items.0"	Primer elemento de payload.order.items

Un campo se considera ausente si su valor es undefined, null o cadena vacía "".

Notas

• El nodo lee el método HTTP desde data._request.method, que es establecido automáticamente por los nodos Webhook y FormTrigger.
• Cuando falla la validación, el flujo termina con _stopflowprocess: true — los nodos siguientes no se ejecutan.
• El body de error automático incluye { "error": true, "message": "..." } con una explicación legible.
• El Código de error y el Cuerpo de error se aplican a ambos tipos de fallo (método no permitido y campo faltante).
• Los datos nunca se modifican — si el filtro pasa, los datos fluyen exactamente como fueron recibidos.

Nodos relacionados

• Webhook — el trigger que establece _request.method
• FormTrigger — otro trigger compatible con este filtro
• Web Response — para devolver respuestas HTTP personalizadas más adelante en el flujo
• Webhook Router — para enrutar tráfico por método HTTP en lugar de bloquearlo