Webhooks en Zapier y Make: Cómo usar (sin dolor)

Implementar webhooks Zapier y Make no tiene por qué ser un sufrimiento. Con un enfoque ordenado —y un par de buenas prácticas— podrás recibir eventos, transformarlos y enviarlos a otros sistemas con fiabilidad. Esta guía te muestra lo esencial para ponerlos en marcha sin fricción.

Aquí verás cómo manejar GET/POST, configurar headers, aplicar seguridad mínima viable y replicar ejemplos reales. Además, te dejo una colección de Postman para que pruebes todo sin escribir una sola línea de código adicional.

Nota: respeta la privacidad y las normativas locales. Esto no es asesoría legal.

Resumen accionable

• Identifica si necesitas catch (entrada) o POST (salida) y mapea campos antes de tocar el builder.
• En Zapier, usa Webhooks by Zapier; en Make, usa los módulos Webhooks y HTTP.
• Para pruebas, envía POST JSON con Content-Type: application/json y valida el payload recibido.
• Protege tus endpoints con secret compartido, IP allowlist o firma HMAC cuando sea posible.
• Registra respuestas (2xx/4xx/5xx) y habilita reintentos o colas en la herramienta origen.
• Normaliza claves (snake_case o camelCase) y documenta el esquema en Postman.
• Antes de producción, ejecuta un flujo end-to-end con datos realistas y verifica logs.

GET/POST

Al trabajar con webhooks, hay dos movimientos básicos: capturar (catch) y enviar (POST). Capturar significa exponer una URL que recibirá eventos de otra app o servicio; enviar es llamar a una URL externa con datos cuando ocurre un trigger en tu flujo. Tanto Zapier como Make soportan ambos patrones: recibir a través de un módulo “Catch Hook” y enviar con un módulo “POST/GET/PUT” según lo que el destino requiera. Empezar por un POST JSON simplifica depuración, ya que los payloads se ven claros y consistentes.

Aunque GET y POST pueden transportar parámetros, en práctica POST es la opción preferida para carga significativa y para pasar objetos anidados. GET queda útil para pings, verificaciones rápidas o webhooks de proveedores que solo validan una suscripción. Define desde el inicio qué método exige cada extremo y prueba con la colección de Postman para eliminar ambigüedades. Mantén un esquema de datos estable y no dependas de cambios silenciosos en la fuente.

Diferencias prácticas entre GET y POST (para webhooks)

Aspecto	GET	POST
Dónde viajan los datos	Query string (?a=1&b=2)	Cuerpo (body), p. ej., JSON
Tamaño típico	Limitado por URL	Mayor y flexible
Uso común	Verificación, health check	Eventos, datos de negocio
Idempotencia	Normalmente leído como idempotente	Depende del diseño; usa idempotency-key
Debug	Fácil de ver en URL	Requiere inspeccionar body/logs

Tras elegir el método, tendrás una base clara para configurar headers y seguridad. Si la fuente solo soporta GET, limita datos a parámetros simples y evita información sensible.

Headers

Los headers transportan metadatos críticos: tipo de contenido, autenticación, firmas y control de idempotencia. En pruebas, define siempre Content-Type: application/json y usa una codificación consistente (UTF-8). Cuando envías desde Zapier o Make, agrega un header de versión (p. ej., X-Event-Version: 1) para facilitar migraciones. Si el destino valida seguridad por firma, verás headers tipo X-Signature o X-Hub-Signature-256 con HMAC; necesitarás replicarlos para pruebas consistentes.

Además, aprovecha headers para trazabilidad: un X-Request-Id único te permitirá correlacionar logs entre sistemas. Si manejas reintentos, incluye Idempotency-Key con un UUID estable por evento, evitando duplicados en el receptor. Documenta en tu colección de Postman los headers obligatorios y opcionales, así cada miembro del equipo puede ejecutar el mismo set de pruebas sin adivinar.

Después de estandarizar headers, la validación de seguridad será más directa y tus flujos se volverán más predecibles durante despliegues.

Seguridad

La seguridad en webhooks equilibra simplicidad y protección. El mínimo viable es un secret compartido entre emisor y receptor, comprobado en cada request (por query o header). Idealmente, usa firmas HMAC: el emisor calcula un hash del body con un secret y lo envía en un header; el receptor recalcula y compara, bloqueando mensajes manipulados. Si tu origen permite allowlist de IPs, úsala para reducir la superficie de ataque, especialmente en endpoints públicos.

No expongas tokens o claves en el payload ni en capturas de pantalla. Si el proveedor ofrece event replay y timestamps, verifica ventanas de validez para evitar replay attacks. Habilita HTTPS siempre; los webhooks en claro (HTTP) no son aceptables en producción. Finalmente, centraliza logs con redacción (redaction) de campos sensibles y restringe el acceso a los historiales en Zapier/Make a perfiles que realmente lo necesiten.

Una vez blindado lo básico, podrás enfocarte en la lógica de negocio y en la observabilidad del flujo.

Diagrama ASCII — Flujo típico de webhook (catch → transformar → POST)

[Sistema A] --POST--> [Webhook Catch (Zapier/Make)] --mapear/filtrar-->
   --reintentos--> [Transformación] --POST--> [API destino]
                               \--> [Logs/Alertas]

Ejemplos

Los siguientes ejemplos te dan un webhook Make tutorial y su equivalente en Zapier, cubriendo entrada (catch) y salida (POST). Acompáñalos con la colección de Postman incluida al final.

1 — Capturar evento (catch) y responder 200

• Zapier: Crea un Zap con Trigger: Webhooks by Zapier → Catch Hook. Copia la URL generada. Envía un POST desde Postman con JSON: { "event": "lead.created", "id": "evt_12345", "payload": { "email": "[email protected]", "source": "ads" } } En el siguiente paso, usa Code/Formatter/Utilities para validar campos y continúa el flujo.
• Make: Crea un escenario con Webhook → Custom webhook (Catch). Guarda la URL. En Postman, repite el POST. Haz clic en Run once y captura la muestra. Añade módulo Tools → JSON para seleccionar campos y continuar.

2 — Enviar evento (POST) a un API externo

• Zapier: Añade acción Webhooks by Zapier → POST. Configura URL del destino, Payload Type: JSON, y headers:
  • Content-Type: application/json
  • X-Request-Id: {{zap_meta_human_now}} (o un UUID)
  • Idempotency-Key: {{id_evento}}
    Define el body con campos mapeados del catch anterior.
• Make: Añade módulo HTTP → Make a request con Method: POST. Define Headers equivalentes y body en JSON. Activa retry del módulo si el destino responde 429/5xx y registra el último estado.

3 — Validación HMAC (concepto)

1. Proveedor envía X-Signature: sha256=<hmac> calculado sobre el body.
2. En tu flujo, calcula de nuevo HMAC_SHA256(body, SECRET).
3. Compara valores; si difiere, devuelve 401/403 y registra intento.

Nota: respeta la privacidad y las normativas locales. Esto no es asesoría legal.

Tras dominar estos patrones, podrás encadenar pasos complejos: bifurcaciones, filtros por campos, y colas de reintento para resiliencia.

Errores comunes

• Enviar application/x-www-form-urlencoded por costumbre cuando el receptor espera JSON.
• No versionar payloads; cambios rompen mapeos silenciosamente.
• Olvidar Idempotency-Key y crear duplicados aguas abajo.
• Exponer secrets en ejemplos, captures o logs sin redacción.
• Confiar en GET para datos sensibles o de gran tamaño.
• Ignorar reintentos y límites de tasa (rate limits) del destino.
• No documentar el esquema ni los headers requeridos en la colección de Postman.

Un repaso final a estos puntos antes del go-live evita regresiones y reduce tickets de soporte.

Checklist / Plantilla (versión resumida del asset)

• Definir método: GET para verificación, POST para eventos.
• Estandarizar headers: Content-Type, X-Request-Id, Idempotency-Key, versión.
• Seguridad: secret/HMAC, HTTPS, allowlist IP si procede.
• Mapeo de campos: normaliza claves y documenta esquema.
• Reintentos: estrategia ante 429/5xx, backoff y límite.
• Logs y alertas: centralizados, con redacción de sensibles.
• Pruebas con Postman: colecciones con ejemplos de catch y POST.
• Validación final: prueba end-to-end con datos realistas.

Asset — Colección Postman (contenido sugerido):

• Carpeta 1: Catch Hooks
  • POST /webhook/zapier-catch (body JSON)
  • POST /webhook/make-catch (body JSON)
• Carpeta 2: Outbound
  • POST /api/destino/event con headers estándar
  • POST /api/destino/event (con Idempotency-Key)
• Carpeta 3: Seguridad
  • Ejemplo de firma X-Signature (HMAC-SHA256) con pre-request script
  • Verificación de timestamp para evitar replay

FAQ

1) ¿Qué diferencia práctica hay entre webhooks y polling?
Los webhooks empujan eventos en tiempo real; el polling consulta periódicamente. Webhooks reducen latencia y consumo, pero exigen exponer endpoints y gestionar seguridad.

2) ¿Uso GET o POST para mi webhook?
Usa POST para eventos con payloads; reserva GET para verificaciones o pings sin datos sensibles.

3) ¿Cómo manejo duplicados?
Incluye Idempotency-Key por evento y registra id_evento en el receptor. Si llega un duplicado con la misma clave, retorna el mismo resultado y no reproceses.

4) ¿Qué hago si el destino devuelve 429/5xx?
Implementa reintentos con backoff exponencial y límites. Si persiste, registra incidente y activa ruta alternativa o cola.

5) ¿Puedo transformar el payload en Zapier/Make?
Sí. Usa utilidades de transformación (p. ej., formateo JSON, código ligero) para normalizar datos antes de enviarlos.