Template — Webhook API Gateway

Este template muestra cómo construir un API gateway REST completo en Floogos usando dos nodos: Webhook Router (divide el tráfico por verbo) y Webhook Filter (valida cada rama). El resultado se comporta como un endpoint HTTP real que soporta GET, POST, PUT y DELETE.

Qué vas a construir

Cada rama es independiente. Agregar un nuevo verbo es tan simple como conectar otro handle.

---

Paso 1 — Trigger Webhook

Arrastra un nodo Webhook al canvas. Este es tu único punto de entrada a la API — una URL maneja todos los métodos.

No se necesita configuración especial. El webhook captura automáticamente el método HTTP y lo pasa como data._request.method.

Consejo

Copia la URL del webhook desde el panel del nodo. Esta es la URL que llamarás desde tu cliente, Postman o sistema externo.

---

Paso 2 — Webhook Router

Arrastra un nodo Webhook Router y conéctalo a la salida del Webhook.

Este nodo no tiene configuración — solo conecta los handles de salida:

Handle	Conectar a
GET	Webhook Filter de la rama GET
POST	Webhook Filter de la rama POST
PUT	Webhook Filter de la rama PUT
DELETE	Webhook Filter de la rama DELETE
Default	Web Response (405)

---

Paso 3 — Webhook Filter por rama

Agrega un Webhook Filter por rama para validar el payload antes de que corra la lógica de negocio.

Rama GET — validar parámetros

{
  "allowGET": true,
  "requiredFields": [],
  "errorCode": "400",
  "errorBody": {}
}

Las peticiones GET frecuentemente no tienen campos de body obligatorios. Deja requiredFields vacío si los parámetros son opcionales.

Rama POST — validar campos del body

{
  "allowPOST": true,
  "requiredFields": ["name", "email"],
  "errorCode": "422",
  "errorBody": {
    "success": false,
    "message": "Faltan campos requeridos: name y email son obligatorios."
  }
}

Rama PUT — validar id y body

{
  "allowPUT": true,
  "requiredFields": ["id", "name"],
  "errorCode": "422",
  "errorBody": {
    "success": false,
    "message": "Faltan campos requeridos: id y name son obligatorios para actualizar."
  }
}

Rama DELETE — validar id

{
  "allowDELETE": true,
  "requiredFields": ["id"],
  "errorCode": "400",
  "errorBody": {
    "success": false,
    "message": "El campo 'id' es requerido para eliminar."
  }
}

:::note Un método por filtro Cada Webhook Filter debería tener habilitado un solo método (el que corresponde a su rama). El Router ya garantiza que solo el método correcto llega a cada rama, pero tener un único método habilitado hace la intención explícita. :::

---

Paso 4 — Nodos de lógica de negocio

Después de cada Webhook Filter, agrega los nodos que realizan el trabajo real.

Ejemplo rama GET — consultar base de datos:

Webhook Filter → SQL Query (SELECT * WHERE id = {{data.id}}) → Web Response 200

Ejemplo rama POST — insertar registro:

Webhook Filter → EditFields (formatear datos) → SQL Query (INSERT) → Web Response 201

Ejemplo rama PUT — actualizar registro:

Webhook Filter → SQL Query (UPDATE WHERE id = {{data.id}}) → Web Response 200

Ejemplo rama DELETE — eliminar registro:

Webhook Filter → SQL Query (DELETE WHERE id = {{data.id}}) → Web Response 204

---

Paso 5 — Nodos Web Response

Agrega un Web Response al final de cada rama con el código HTTP apropiado.

Rama	Código HTTP	Body típico
GET (encontrado)	200	Datos del resultado
GET (no encontrado)	404	{ "error": "No encontrado" }
POST (creado)	201	Registro creado
PUT (actualizado)	200	Registro actualizado
DELETE (eliminado)	204	(body vacío)
Default (método incorrecto)	405	{ "error": "Método no permitido" }

Configuración Web Response 405 (rama Default):

{
  "code_response": 405,
  "body_response": {
    "error": true,
    "message": "Método no permitido. Métodos soportados: GET, POST, PUT, DELETE."
  },
  "headers": {
    "Allow": "GET, POST, PUT, DELETE"
  }
}

---

Nodos utilizados

Nodo	Cantidad	Función
Webhook	1	Punto de entrada único
Webhook Router	1	Divide el tráfico por método HTTP
Webhook Filter	4	Valida el payload por rama
[Nodos de lógica]	4+	SQL Query, HTTP, DataStore, etc.
Web Response	5+	Devuelve respuestas HTTP

---

Probar la API

Usa Postman, curl o cualquier cliente HTTP para probar cada rama:

# GET — listar elementos
curl -X GET https://tu-webhook-url

# POST — crear elemento
curl -X POST https://tu-webhook-url \
  -H "Content-Type: application/json" \
  -d '{"name": "Alice", "email": "alice@ejemplo.com"}'

# PUT — actualizar elemento
curl -X PUT https://tu-webhook-url \
  -H "Content-Type: application/json" \
  -d '{"id": 42, "name": "Alice Actualizada"}'

# DELETE — eliminar elemento
curl -X DELETE https://tu-webhook-url \
  -H "Content-Type: application/json" \
  -d '{"id": 42}'

# PATCH — debería devolver 405
curl -X PATCH https://tu-webhook-url

Comportamiento esperado:

Petición	Respuesta esperada
GET	200 + datos
POST con name+email	201 + registro creado
POST sin email	422 + mensaje de error
PUT con id+name	200 + registro actualizado
DELETE con id	204
PATCH	405 Method Not Allowed

---

Variaciones

Variación A — Solo Filter sin Router (API más simple)

Si solo aceptas POST:

Webhook → Webhook Filter (allowPOST, requiredFields) → Lógica → Web Response

Usa el Webhook Router solo cuando necesites manejar múltiples métodos en el mismo endpoint.

Variación B — Capa de autenticación

Agrega un nodo HTTP Request antes del Router para llamar a un servicio de auth:

Variación C — Rate limiting con DataStore

---

Nodos relacionados

• Webhook — punto de entrada
• Webhook Filter — validación de payload
• Webhook Router — enrutamiento por método HTTP
• Web Response — respuestas HTTP
• Switch — enrutamiento basado en condiciones sobre campos de datos