Qué es un webhook y para qué lo vas a necesitar de verdad

Un webhook es un aviso automático. Cuando pasa algo en un sitio (alguien rellena un formulario, alguien paga, alguien se da de baja), ese sitio manda un mensaje a una dirección que tú le has dado, con los datos de lo que acaba de pasar.

Ya está. Esa es toda la definición. El resto del post es para que entiendas por qué esa tontería cambia cómo montas las cosas.

Yo tardé una barbaridad en pillarlo porque la palabra sale en todos los tutoriales y nadie se para a explicarla. Te dicen "y aquí pegas la URL del webhook" como si eso significara algo. Y tú pegas la URL, funciona, y sigues sin tener ni idea de qué acabas de hacer.

¿Qué es un webhook?

Un webhook es una URL que tú le das a un servicio para que te avise cuando ocurra algo concreto.

La palabra viene de "hook", gancho. Enganchas un aviso a un evento. Cuando el evento ocurre, el servicio llama a tu URL y le pasa la información en un paquete de texto (normalmente en formato JSON, que es simplemente datos ordenados con nombres y valores).

La diferencia con lo que hacías antes es el sentido de la flecha. Sin webhook, tú tienes que preguntar cada X minutos "¿ha pasado algo?, ¿y ahora?, ¿y ahora?". Con webhook, te callas y esperas, y el otro te llama cuando hay novedad.

Es la diferencia entre estar mirando el buzón cada diez minutos por si ha llegado una carta, y que el cartero llame al timbre.

Un ejemplo con mi propia web

En rubenloan.com tengo varios tests. Cuando alguien termina un test y deja su correo, pasan varias cosas: se guarda en la base de datos, se le manda un email con el resultado y se le añade a una lista.

Podría tener un proceso que cada cinco minutos mirase la base de datos buscando registros nuevos. Sería una chapuza: o miras demasiado a menudo y gastas recursos para nada, o miras poco y la gente recibe su email veinte minutos tarde.

Con webhook es otra cosa. En cuanto alguien termina el test, mi web lanza el aviso a una URL. Al otro lado hay un flujo esperando. El aviso llega con el nombre, el correo y el resultado del test dentro. El flujo coge esos datos y hace lo que tiene que hacer. Tiempo total: un segundo o dos.

El código que dispara el aviso son cuatro líneas. Literalmente. Lo complicado no es montarlo, es entender qué estás montando.

Tres ejemplos más, de los de verdad

Cobros. Cuando alguien compra un curso, la pasarela de pago (Stripe, Hotmart, la que sea) manda un webhook a tu sistema diciendo "este correo ha pagado esto". Tu sistema le da acceso automáticamente. Sin webhook estarías dando accesos a mano y por la noche, que es cuando compra la gente.

Contenido. Cuando subo un vídeo nuevo a YouTube, YouTube puede avisar a un sistema mío. Ese aviso desencadena lo que yo quiera: guardar el ID del vídeo, preparar el post gemelo, mandarme un recordatorio de programar el corto.

Despliegues. Esta es la que uso todos los días y no me doy ni cuenta. Cuando hago push de un cambio a GitHub, GitHub manda un webhook a mi servidor. El servidor recibe el aviso, se baja los cambios, reconstruye la web y la reinicia. Yo escribo, hago push, y dos minutos después está en producción sin que haya tocado nada más.

Ese último caso es el que mejor explica para qué sirven. No es que sea imposible hacerlo sin webhook. Es que sin webhook alguien tendría que apretar un botón. Y ese alguien serías tú, siempre.

¿Cómo se ve un webhook por dentro?

Un webhook es una petición HTTP. La misma tecnología con la que tu navegador pide páginas web, pero al revés y sin navegador.

Tiene tres partes que te importan:

La URL. El sitio al que se manda el aviso. Te la da la herramienta que va a recibirlo. Si usas n8n para automatizar, pones un nodo de tipo Webhook al principio del flujo y te genera una URL única. Esa URL es la dirección de tu buzón.

El método. Casi siempre POST, que en lenguaje HTTP significa "te traigo datos". No tienes que hacer nada con esto, pero cuando veas el desplegable ya sabes qué elegir.

El cuerpo. Los datos. Un bloque de texto con la información del evento: quién, qué, cuándo, cuánto. Aquí es donde está lo que a ti te interesa.

Cuando montes tu primer flujo, el truco es dispararlo una vez a lo tonto solo para ver qué llega. Ejecutas el evento de verdad (rellenas tu propio formulario, haces una compra de prueba), miras lo que ha aterrizado en el flujo, y a partir de ahí ya sabes qué campos tienes disponibles. Te lo explico paso a paso en el tutorial de webhooks con n8n.

Lo que un webhook no es

No es una API. Se confunden constantemente porque las dos cosas mueven datos entre programas, pero van en direcciones distintas. Con una API tú pides. Con un webhook a ti te avisan. Si quieres la explicación larga, tengo un post entero sobre qué es una API sin tecnicismos.

No es una conexión permanente. No hay un cable abierto entre los dos sistemas. Es un mensaje suelto que se manda y se acaba. Si el que recibe está caído en ese momento, el mensaje se pierde (algunos servicios reintentan unas cuantas veces, otros no).

No es seguro por defecto. La URL de un webhook es pública. Cualquiera que la adivine puede mandarte datos falsos. Por eso los servicios serios firman los avisos con una clave, y tú compruebas la firma antes de fiarte. Si estás moviendo algo que importa (pagos, accesos), esto no es opcional.

No es tiempo real garantizado. Es rápido, normalmente instantáneo. Pero si tu servidor tarda en responder, o el otro tiene la cola llena, puede llegar con retraso. Diseña pensando en "casi siempre en un segundo", no en "exactamente ahora".

¿Cuándo necesitas uno y cuándo no?

Necesitas un webhook cuando hay un evento que no controlas y quieres reaccionar sin esperar. Alguien compra, alguien se apunta, alguien comenta, un archivo cambia. Tú no sabes cuándo va a pasar, así que la única alternativa es preguntar en bucle. Mal negocio.

No lo necesitas cuando el evento lo generas tú mismo dentro del mismo sistema. Si tu propia aplicación tiene que hacer dos cosas seguidas, hazlas seguidas. Meter un webhook ahí es dar una vuelta al mundo para cruzar la calle.

Tampoco lo necesitas para procesos que van por horario. Si algo tiene que pasar todos los días a las nueve, eso es un programador de tareas, no un webhook. Nadie te tiene que avisar de que son las nueve.

La regla que uso: si la frase que describe lo que quiero empieza por "cuando alguien...", es un webhook. Si empieza por "cada día...", no lo es.

Por dónde empezar sin morir en el intento

Monta uno de mentira. En serio, es la mejor forma de que se te caiga la venda.

Abre una herramienta de automatización, crea un flujo nuevo, pon un disparador de tipo webhook y copia la URL que te da. Después pega esa URL en cualquier servicio que tengas a mano y que ofrezca webhooks (un formulario, una tienda, lo que sea). Dispara el evento. Vuelve al flujo y mira lo que ha llegado.

Ese momento en el que ves aparecer tus propios datos en la pantalla es cuando el concepto deja de ser una palabra de tutorial y se convierte en una herramienta. A mí me pasó exactamente así, y desde entonces la mitad de las cosas que tengo montadas empiezan con un webhook.

Lo demás es aprender a encadenar: recibo el aviso, filtro, transformo, mando a otro sitio. Eso ya es automatización, y de eso va el hub de automatización y agentes con IA.

Si no tienes claro por dónde meter la IA y la automatización en lo que ya haces, he montado un test corto que te dice qué tipo de usuario de IA eres y qué te conviene montar primero.

Hacer el test de IA