Una de las decisiones de arquitectura más subestimadas al diseñar un workflow en n8n es cómo se dispara la ejecución. Polling es la opción default de muchos nodos (Schedule Trigger, Gmail Trigger, varios más). Webhooks son la alternativa que casi siempre produce mejor resultado cuando la app de origen los soporta. La mayoría de los equipos nunca se preguntan cuál usar y terminan eligiendo polling por omisión, pagando un costo que podrían evitar.
Este post explica la diferencia, cuándo importa y cómo tomar la decisión correcta.
Qué hace cada uno
Polling es la estrategia de preguntar. Tu workflow corre cada N minutos, chequea si hay novedades en el sistema de origen, y procesa lo que encuentra. Si no hay nada, cierra y espera al próximo intervalo. Si hay algo, procesa y cierra.
Webhooks es la estrategia de escuchar. El sistema de origen, cuando algo pasa, llama a una URL pública de tu workflow. Tu workflow se dispara solo en respuesta a ese llamado, procesa el evento y cierra. No hay ejecuciones vacías porque no hay ejecuciones cuando no hay eventos.
En palabras simples: polling es "¿hay algo nuevo? ¿y ahora? ¿y ahora?". Webhooks es "avisame cuando haya algo nuevo".
Por qué polling es seductor pero casi siempre peor
Polling es el default porque es más simple de configurar. No requiere que el sistema de origen soporte nada especial, no necesitás URL pública, no pelearte con firmas de seguridad ni con retries. Abrís el nodo, ponés "cada 15 minutos", y listo.
El problema es que esa simplicidad se paga en ejecuciones. Un workflow que polea cada 15 minutos, 24/7, ejecuta 96 veces por día. Si nada cambió en el sistema de origen, 95 de esas ejecuciones fueron literalmente inútiles. Si algo cambió 5 minutos después de una ejecución, el siguiente procesamiento se demora casi 15 minutos.
Los efectos secundarios:
Costo de ejecuciones. n8n Cloud cobra por ejecuciones en los planes limitados. Polling genera muchísimas ejecuciones, la mayoría vacías. En self-hosted el costo es en CPU y capacidad del VPS, menos directo pero real.
Latencia de procesamiento. Cuando usás polling, el tiempo que pasa entre que el evento ocurre y tu workflow lo procesa es, en promedio, la mitad del intervalo. Si poleás cada 15 minutos, el promedio de espera es 7.5 minutos. Para muchos casos de uso (confirmar un pedido, responder a un cliente, disparar un aviso), ese delay es inaceptable.
Rate limits de la API de origen. Polear muy frecuentemente contra una API con límites (Google, Microsoft, Slack, la mayoría) te lleva rápido a 429. Muchos equipos descubren esto después de activar el workflow y tener que subir el intervalo a 30 minutos, agravando el problema de latencia.
Pérdida de eventos. Si el volumen es alto y entre dos polls ocurren más eventos de los que podés procesar en una ejecución, algunos eventos no se van a ver. Suena raro pero pasa, especialmente con APIs que solo devuelven "los últimos N items".
El cálculo del costo real de polling
Hagamos cuentas concretas. Un workflow que polea una API cada 15 minutos durante 30 días:
- Ejecuciones totales: 96 × 30 = 2.880.
- Ejecuciones "útiles" (asumiendo que hay un evento real por día en promedio): 30.
- Ejecuciones vacías: 2.850.
O sea, el 99% de las ejecuciones son ruido. Si usaras webhook, tendrías 30 ejecuciones en el mes, todas significativas. La diferencia de costo en n8n Cloud (donde ejecuciones están limitadas o facturadas) es considerable. La diferencia de CPU en self-hosted es medible pero menor.
Y el costo más importante no es dinero: es la latencia. Con webhook, el evento se procesa en segundos. Con polling cada 15 min, en promedio demora 7.5 minutos. Ese delay puede destruir la UX de un proceso que los usuarios esperaban "en tiempo real".
Cuándo polling es la opción correcta
No todos los casos sirven para webhooks. Hay situaciones donde polling es la única opción o incluso la mejor opción.
APIs que no soportan webhooks. Sucede. Algunas APIs viejas, sistemas legacy internos, herramientas de nicho, o APIs que solo soportan webhooks en planes caros. Si el sistema de origen no puede llamarte, no hay webhook. Polling es el camino.
Eventos que agrupás en batch. A veces no querés procesar cada evento en cuanto ocurre. Querés juntar todos los eventos del día y procesarlos en bloque (por ejemplo, generar un reporte diario a las 2 AM). Ahí no necesitás webhooks; necesitás un Schedule Trigger puro. No es polling en el sentido estricto, es procesamiento programado.
Sistemas donde el estado importa más que el evento. Algunos workflows no responden a eventos individuales; responden a cambios de estado. "Si hay más de 100 filas nuevas en esta tabla, generar alerta." Para eso, polling periódico es natural porque la unidad de análisis no es el evento sino el snapshot.
APIs internas simples. Si la integración es contra un sistema interno tuyo donde vos controlás todo, puede que polling sea más simple que implementar un webhook interno. Para casos chicos, la simplicidad gana.
Cómo configurar webhooks en 3 plataformas comunes
Para los casos donde webhook es la opción correcta, la configuración varía por plataforma pero sigue patrones similares.
Google Workspace (Drive, Gmail, Calendar). Google no tiene webhooks directos para la mayoría de estos servicios. Lo que tiene son "push notifications" a una URL pública usando Google Cloud Pub/Sub. Es webhook pero con capas. El patrón típico: configurás un topic de Pub/Sub, suscribís tu URL de n8n como endpoint, y Google empuja eventos al topic cuando ocurren. n8n tiene nodos para recibir esas notificaciones.
Slack. Slack tiene webhooks oficiales vía Events API. Creás una app de Slack, la configurás para recibir los eventos que te interesan (mensaje enviado, reacción, archivo subido, etc.), y ponés una URL de tu n8n como endpoint. Slack verifica la URL con un handshake inicial y empieza a enviar eventos. Bastante directo.
Stripe. Stripe tiene webhooks maduros y bien documentados. Creás un endpoint en el dashboard de Stripe, seleccionás qué eventos te interesan (pago completado, suscripción cancelada, chargeback, etc.), y Stripe envía eventos con retries automáticos si tu endpoint no responde 200. Para producción, activá la verificación de firma (ver siguiente sección).
En los tres casos, n8n tiene un nodo Webhook genérico que recibe cualquier POST y pasa el body al workflow. Es todo lo que necesitás para empezar.
Seguridad: verificación de firma HMAC
Un webhook es una URL pública. Eso significa que cualquiera puede enviar POSTs a esa URL, no solo el sistema legítimo. Si tu workflow confía ciegamente en lo que recibe, un atacante puede inyectar datos falsos, disparar ejecuciones no autorizadas, o incluso causar daño directo (imagínate un webhook que dispara transferencias bancarias).
La mitigación estándar es la verificación de firma HMAC. Funciona así: el sistema de origen firma cada request con una clave secreta compartida, incluyendo un hash del body. Tu workflow verifica ese hash con la misma clave antes de procesar. Si el hash no coincide, el request es falso y se descarta.
La mayoría de las APIs serias (Stripe, GitHub, Slack, Shopify, Tiendanube) tienen este mecanismo. Configurarlo requiere 5-10 minutos adicionales y salta de "cualquiera puede abusar" a "solo el origen legítimo puede disparar". No es opcional para workflows de producción con webhooks expuestos.
En n8n, la verificación se implementa con un nodo inicial después del Webhook Trigger que calcula el hash del body recibido y lo compara contra el header de firma. Si no coincide, interrumpe la ejecución con un IF que sale a un branch "reject".
La regla simple
Cuando arrancás un workflow nuevo, hacé las siguientes preguntas en orden:
-
¿La API de origen soporta webhooks o push notifications? Si sí, seguí a la pregunta 2. Si no, polling es la única opción.
-
¿Necesitás procesar eventos individuales, o agregados batch? Si individuales, webhook. Si batch periódico, Schedule Trigger (no es polling en sentido estricto).
-
¿La latencia importa? Si sí, webhook. Si podés tolerar 15+ minutos de delay, polling es aceptable pero todavía inferior.
-
¿Tenés URL pública con HTTPS para tu n8n? Si sí, podés recibir webhooks. Si no (ejemplo: n8n corriendo en red privada), necesitás túnel (ngrok-style) o polling.
En la mayoría de los casos de PyME que tocamos, las respuestas llevan a webhook. El patrón es: los equipos arrancan con polling por inercia, descubren las limitaciones después de un tiempo, y reescriben para webhook. Ahorrarse ese reescribir arrancando bien desde el principio es una de las decisiones baratas con más impacto en la calidad del proyecto.
Un caso real
Un cliente nos pidió un workflow que sincronizara pedidos de su tienda (Tiendanube) a su ERP cada vez que se crean. El equipo interno había armado una primera versión con Schedule Trigger cada 10 minutos que leía los últimos 20 pedidos de Tiendanube vía API y los actualizaba en el ERP.
Problemas observables después del primer mes:
- El equipo de atención al cliente veía pedidos "demorados" que no aparecían en el ERP hasta 10 minutos después. Para ellos parecía un bug.
- Ocasionalmente, días con mucho volumen hacían que algunos pedidos "se perdieran" porque llegaban más de 20 entre pulls.
- La API de Tiendanube empezaba a devolver 429 en horas pico, rompiendo el sync y haciendo que algunos pedidos se procesaran con más de una hora de demora.
Solución: reemplazar polling por webhook. Tiendanube soporta webhooks para eventos de pedido. Configuramos el webhook apuntando a una URL de n8n, activamos la verificación de firma, y el workflow pasó de 1.440 ejecuciones diarias vacías a ~200 ejecuciones diarias útiles. La latencia bajó de 5 minutos promedio a menos de 5 segundos. Los problemas de pedidos perdidos y rate limits desaparecieron.
Tiempo de implementación del cambio: media jornada. Ahorro operativo y mejora de UX: permanente.
El punto
Polling es la decisión por inercia y casi siempre se paga. Webhooks requieren un poco más de setup inicial y un poco de disciplina de seguridad, pero producen workflows más rápidos, más baratos de operar y más confiables. Antes de aceptar el default de polling en un proyecto nuevo, pregúntate si la API de origen soporta webhooks. En 2026, la mayoría lo hace.