Claves rápidas
- Un webhook es un aviso automático que una aplicación envía a otra cuando pasa algo. No lo pides tú: lo manda el sistema donde ocurrió el evento, en el momento en que ocurre, a una dirección que tú has registrado antes.
- La diferencia con una API tradicional es quién llama a quién. Con una API preguntas tú cada pocos minutos. Con un webhook te llaman a ti una sola vez, y esa asimetría cambia todo lo demás.
- El problema real no es entender el concepto, es la entrega. Muchos proveedores envían cada evento una sola vez y sin reintentos, así que si tu servidor estaba caído ese aviso no vuelve.
- Para un equipo comercial, el caso típico cabe en una frase. Se confirma una reserva, el webhook avisa, y el contacto aparece en el CRM con la tarea de seguimiento ya creada, sin que nadie copie nada a mano.
La mayoría de explicaciones sobre webhooks terminan en la analogía del timbre y se quedan tan anchas. El concepto se entiende en treinta segundos; lo que de verdad decide si tu automatización funciona en marzo es lo que pasa cuando la entrega falla, cuando el mismo evento llega dos veces o cuando alguien envía a tu endpoint un aviso falso. Aquí tienes la definición clara, un ejemplo de reserva seguido de principio a fin, y la parte incómoda que casi ninguna guía cuenta.
Qué es un webhook
Un webhook es una petición HTTP que un sistema envía de forma automática a una URL tuya cuando se produce un evento concreto. En la práctica son tres piezas:
- El emisor. La plataforma donde pasa algo: una pasarela de pago, un formulario, una herramienta de reservas.
- El evento. El hecho concreto que dispara el aviso: un pago confirmado, una cita reservada, una cancelación.
- El receptor. Tu endpoint, una URL pública que escucha y hace algo con lo que recibe.
El emisor manda normalmente un POST con los datos del evento en formato JSON. El receptor contesta con un código 2xx para decir "recibido". Ahí acaba la conversación.
Por eso se le llama a veces API inversa o callback HTTP: la dirección de la llamada está invertida respecto a lo que hacemos habitualmente con una API.
Webhook o API: la diferencia en una tabla
Las dos cosas usan HTTP y las dos mueven JSON, así que es fácil confundirlas. Lo que cambia es quién inicia la conversación.
| API tradicional (polling) | Webhook (push) | |
|---|---|---|
Quién llama | Tu sistema pregunta | El otro sistema avisa |
Quién llama API tradicional (polling)Tu sistema pregunta Webhook (push)El otro sistema avisa | ||
Cuándo | Cada X minutos, haya novedad o no | En el instante del evento |
Cuándo API tradicional (polling)Cada X minutos, haya novedad o no Webhook (push)En el instante del evento | ||
Latencia | Tan alta como tu intervalo | Prácticamente inmediata |
Latencia API tradicional (polling)Tan alta como tu intervalo Webhook (push)Prácticamente inmediata | ||
Coste | Muchas peticiones vacías | Una petición por evento |
Coste API tradicional (polling)Muchas peticiones vacías Webhook (push)Una petición por evento | ||
Lo difícil | Elegir el intervalo | Que no se te escape un aviso |
Lo difícil API tradicional (polling)Elegir el intervalo Webhook (push)Que no se te escape un aviso | ||
Si consultas una API cada minuto, tu dato puede tener hasta 59 segundos de antigüedad y habrás gastado 1.440 peticiones diarias para enterarte de tres cosas. El webhook invierte esa economía. A cambio, asume una responsabilidad nueva: tienes que estar escuchando.
Ninguna de las dos sustituye a la otra. Lo habitual es usar el webhook para enterarte de que algo ha pasado y la API para pedir el detalle completo cuando lo necesitas.
Cómo funciona paso a paso: una reserva que acaba en el CRM
Este es el recorrido completo, con el ejemplo más común en un equipo comercial.
1. Registras tu URL en el emisor
Entras en la configuración de la herramienta de reservas y añades la dirección de tu endpoint, algo tipo https://tuempresa.com/hooks/reservas. Tiene que ser HTTPS y tiene que ser accesible desde internet, no desde tu red local.
2. Eliges los eventos
Nadie quiere recibirlo todo. Seleccionas solo los eventos que vas a tratar: reserva creada, reserva cancelada, reserva reprogramada. Cada evento que activas sin tener código que lo procese es ruido que luego cuesta depurar.
3. Ocurre el evento
Un cliente reserva una demo el martes a las 10:00. En ese momento, la plataforma genera el aviso.
4. El emisor envía el POST
Tu servidor recibe una petición con el cuerpo en JSON. Simplificado, se parece a esto:
POST /hooks/reservas HTTP/1.1
Content-Type: application/json
{
"event": "booking_created",
"booking_id": "bk_8f21c",
"start": "2026-10-14T10:00:00+02:00",
"invitee": {
"name": "Marta Ruiz",
"email": "marta@cliente.es",
"company": "Cliente SL"
},
"meeting_type": "Demo producto"
}5. Tu sistema hace algo con ello
Aquí es donde el webhook deja de ser teoría. Con ese JSON puedes crear el contacto en el CRM, asignarlo al comercial del territorio, programar un correo de preparación para el día anterior y abrir una tarea de seguimiento a 48 horas vista de la reunión.
Lo que antes era "acuérdate de pasar la reserva al CRM" pasa a ocurrir solo. Y la diferencia se nota justo cuando el equipo está desbordado, que es cuando ese copiado manual se abandona.
Si no quieres escribir código para el paso 5, las plataformas de automatización se colocan ahí en medio: tú apuntas el webhook a Make, a n8n o a Zapier, y el resto lo montas arrastrando bloques. Es la vía normal para un equipo sin desarrollador disponible.
La parte que casi nadie cuenta: la entrega
Aquí es donde las automatizaciones mueren en silencio. Tres cosas que conviene decidir antes de poner nada en producción.
Un intento y ya está
Muchos proveedores envían cada evento una sola vez, sin reintentos automáticos. Si tu endpoint devolvió un error 500 porque estabas desplegando, ese aviso se perdió y nadie te va a avisar de que te lo perdiste.
La defensa estándar es no procesar nada dentro de la petición: responde 2xx en cuanto recibes, mete el evento en una cola y procesa después. Si no tienes infraestructura para eso, una herramienta de automatización con reintentos propios hace el mismo papel.
El mismo evento, dos veces
Las redes duplican peticiones. Tu receptor tiene que ser idempotente, que es una palabra fea para una idea sencilla: procesar el mismo evento dos veces debe dar el mismo resultado que procesarlo una. Guarda el identificador del evento y descarta los repetidos.
Sin esto, el cliente que reservó una demo acaba con dos registros en el CRM y dos correos de confirmación.
Cualquiera puede llamar a tu URL
Tu endpoint es público. Si no verificas quién llama, cualquiera que descubra la dirección puede inventarse reservas en tu CRM.
Por eso los emisores firman cada petición. El estándar abierto más extendido es Standard Webhooks, mantenido por un comité técnico con gente de Zapier, Twilio, Supabase, Kong y Svix, que define tres cabeceras (webhook-id, webhook-timestamp y webhook-signature) y publica librerías de verificación en Python, JavaScript, Go, PHP y otros lenguajes. Verificar la firma son cinco líneas de código y es la diferencia entre un endpoint y un agujero.
Ejemplos de webhooks en el día a día
Los webhooks no son cosa de desarrolladores: casi cualquier herramienta de negocio los emite.
- Pago confirmado. La pasarela avisa y tu sistema marca la factura como cobrada. Si cobras una señal al reservar, el aviso de Stripe es lo que cierra el círculo.
- Formulario enviado. Un lead rellena el formulario de la web y entra en la lista de reparto comercial antes de que cierre la pestaña.
- Documento firmado. Se completa la firma de un contrato y arranca el alta del cliente.
- Cita cancelada. Se libera el hueco, se avisa a quien estaba en lista de espera y la oportunidad vuelve a la etapa anterior del embudo. Este es el que más dinero recupera de los cuatro, porque el hueco cancelado que nadie rellena se paga igual.
El patrón se repite: un hecho en una herramienta, una consecuencia automática en otra.
Los webhooks en meetergo: lo que está documentado hoy
Antes de prometerle nada a tu equipo, estos son los datos verificados de la integración de webhooks de meetergo (consultado el 2026-10-10):
- Disponibles desde el plan Light, con un máximo de 6 webhooks por cuenta. Los precios por plan están publicados en la web.
- Eventos documentados con nombre:
booking_created,booking_rescheduled,booking_cancelled,form_submission,signature_completed,space_file_uploadedyspace_task_completed, dentro de un catálogo más amplio que incluye reasignación de reservas y actividad del portal de cliente. - Firma según Standard Webhooks, con las cabeceras
webhook-id,webhook-timestampywebhook-signature. El secreto es único por cuenta, solo lo ven los administradores y al rotarlo se firma con el secreto antiguo y el nuevo durante 24 horas. - Cada evento se envía una vez, sin reintentos automáticos. Si tu endpoint responde 410, el webhook se elimina solo.
- La propia documentación recomienda amortiguar los eventos con una cola en Make, n8n o Zapier cuando la entrega tiene que estar garantizada.
Esa última línea dice más que cualquier argumento de venta: el comportamiento está descrito con sus límites en vez de vendido como infalible. Antes de montar nada encima, confirma en tu cuenta qué eventos aparecen en el desplegable, porque el catálogo ha ido creciendo.
Dónde encaja esto en el flujo completo: la reserva entra por la página de citas, el webhook o la automatización la empuja al CRM de meetergo o al tuyo vía HubSpot o Pipedrive, y los recordatorios salen de los flujos de trabajo sin tocar código. Para lo que el webhook no cubre, hay API REST con token personal.
¿Probar la agenda y las automatizaciones de meetergo gratis? El plan gratuito no caduca y no pide tarjeta.
Cinco errores al montar tu primer webhook
- Procesar dentro de la petición. Tu lógica tarda 8 segundos, el emisor corta a los 5, y el evento consta como fallido aunque lo hayas tratado bien. Responde primero, trabaja después.
- No verificar la firma. Es el fallo con peor relación entre esfuerzo de arreglo y consecuencia de no arreglarlo.
- Activar todos los eventos "por si acaso". Multiplica el tráfico y entierra en ruido el evento que sí te importaba.
- Probar solo con el caso feliz. Prueba también la cancelación, la reprogramación y el payload con campos vacíos, que es donde se rompe la mayoría.
- No registrar nada. Sin un log de lo que llegó, el día que falte una reserva en el CRM no vas a poder saber si el aviso no llegó o si tu código lo descartó.
El tercero es el más frecuente en equipos no técnicos, y el quinto el que más tiempo cuesta cuando aparece.
Webhooks y RGPD: qué mirar antes
Un payload de reserva lleva nombre, correo y empresa de una persona identificada, así que es un tratamiento de datos personales como cualquier otro.
Tres comprobaciones concretas antes de enviar nada a un endpoint externo:
- Quién recibe. Si el receptor es un tercero, suele hacer falta un contrato de encargado de tratamiento. El artículo 28 del RGPD detalla qué tiene que incluir.
- Qué viaja. Manda lo mínimo. Si tu automatización solo necesita el correo y la hora, no hay motivo para enviar las respuestas del formulario de calificación.
- Dónde acaba. Un webhook hacia un servicio fuera de la UE es una transferencia internacional con sus propios requisitos. La Agencia Española de Protección de Datos publica guías sobre esto, y en dónde se alojan los datos de meetergo puedes ver la parte que corresponde al emisor.
Y una recomendación práctica: guarda el log de los eventos recibidos con un plazo de borrado definido. Un registro eterno de reservas en un servidor de pruebas es exactamente el tipo de copia que nadie recuerda al atender un derecho de supresión.
Reservas + videoconferencia en una sola herramienta.
Reservas + videoconferencia en una sola herramienta.
Preguntas frecuentes
¿Necesito saber programar para usar webhooks?
Para escribir tu propio receptor, sí. Para usarlos, no: apuntando el webhook a Make, n8n o Zapier montas el flujo con bloques visuales, que es como lo resuelven la mayoría de equipos pequeños.
¿Qué diferencia hay entre un webhook y una integración nativa?
La integración nativa ya viene hecha y configurada por el proveedor. El webhook es materia prima: te da el evento y decides tú qué hacer con él. Si existe integración nativa para tu herramienta, empieza por ahí.
¿Cuánto tarda en llegar un webhook?
Segundos en condiciones normales. No es un canal con garantía de tiempo, así que no construyas encima nada que dependa de una entrega en menos de un segundo.
¿Qué pasa si mi servidor está caído cuando se envía?
Depende del emisor. Algunos reintentan con espera creciente; otros envían una sola vez y el aviso se pierde. Es lo primero que hay que mirar en la documentación, antes de escribir una línea.
¿Puedo enviar un webhook a varias URL a la vez?
Normalmente sí, registrando varios endpoints, aunque suele haber un límite por cuenta. Si necesitas repartir el mismo evento a muchos destinos, es más limpio recibirlo en un sitio y distribuirlo desde ahí.
¿Son seguros los webhooks?
Lo son si verificas la firma, usas HTTPS y compruebas la marca de tiempo para descartar peticiones repetidas. Sin esas tres cosas, un endpoint abierto acepta lo que le mande cualquiera.
¿Un webhook sustituye a la API?
No. El webhook te dice que algo ha pasado; la API te deja consultarlo y modificarlo. Lo normal es combinarlos: recibes el aviso y, si necesitas más contexto, lo pides por API.
Conclusión
Un webhook es un aviso automático entre dos sistemas: emisor, evento y receptor. Esa parte se entiende rápido. Lo que separa una automatización que sigue funcionando dentro de seis meses de una que se rompió sin que nadie se enterara son tres decisiones, y ninguna tiene que ver con la definición: verificar la firma, responder rápido y procesar después, y descartar los eventos duplicados.
Si vas a empezar por un caso, empieza por la reserva que entra en el CRM con su tarea de seguimiento ya creada. Es el que más tiempo manual elimina y el más fácil de verificar al día siguiente. Para el contexto alrededor, la guía de qué es un CRM cubre el lado del receptor, y la de integrar reservas online en tu página web cubre el lado del emisor.
