Webhooks · Actualizado 6 abr 2026 · ~7–10 min

Webhooks en Make (2026)

Los webhooks son la forma más limpia de disparar escenarios al instante cuando ocurre un evento (pago, pedido, formulario, lead…).

En cuanto usas webhooks, tu escenario se comporta como un endpoint “de producción”. Por eso conviene tratarlo como tal.

1) Instant (webhook) vs scheduled (polling)

• Instant: el evento se envía a tu webhook → rápido y eficiente.
• Polling: consultas cada X minutos → simple, pero puede generar muchas ejecuciones vacías.

Si la fuente ofrece webhooks fiables, suele ser mejor opción.

2) Setup paso a paso (flujo recomendado)

Arquitectura típica:

1. Custom webhook (trigger)
2. Validación (campos obligatorios, tipos, allowlist de eventos)
3. Dedupe/idempotencia (ID de evento)
4. Router por tipo (y/o reglas de negocio)
5. Escritura en destinos (CRM, Slack, Sheets…)
6. Opcional: Webhook response

Consejo: mantén el “camino de respuesta” ligero. Responder lento puede provocar reintentos en el proveedor.

3) Diseño del payload (para escalar sin dolor)

Un payload robusto incluye:

• event_id (o clave única)
• event_type
• timestamp
• version

Si tú envías el webhook desde tu sistema, añadir estos campos desde el inicio te ahorra horas de debug más adelante.

4) Seguridad (y RGPD)

Mínimos:

• valida estructura y tipos (no confíes en campos sin comprobar)
• usa secreto/token
• verifica firma si existe
• evita logs con PII innecesaria

RGPD: reduce datos, define finalidad y documenta a qué sistemas se envían (flujo de datos).

5) Reintentos y errores

Los reintentos suelen venir de:

• timeouts,
• rate limits,
• errores transitorios.

Buenas prácticas:

• idempotencia (reintento ≠ duplicado)
• backoff en llamadas a API
• error handlers + alertas
• ruta de “eventos problemáticos” para re-procesar sin bloquear todo

6) Operaciones y coste

Controla operaciones con:

• filtros tempranos (descartar eventos irrelevantes)
• límites/paginación en loops
• batching cuando sea posible
• retries con límites y condiciones