Módulo 7: Calendly y Agendamiento

Webhooks de Calendly

Descripción de la cápsula

Esta es la cápsula central del módulo. Todo lo anterior fue preparación; aquí está el corazón: el webhook de Calendly — la señal que enciende tu automatización en el instante en que alguien reserva.

Un webhook es un concepto que ya viste en G2-M01: en lugar de que tu workflow esté preguntando "¿alguien reservó?" cada cierto tiempo (polling), Calendly te avisa en el momento exacto en que pasa. Es push, no pull. Tiempo real. Cuando Ana termina de reservar su llamada, milisegundos después tu workflow ya se está ejecutando con sus datos.

En n8n, esto se hace con el Calendly Trigger. Esta cápsula te enseña a configurarlo, a elegir a qué eventos suscribirte (invitee.created, invitee.canceled), y a manejar el detalle que define la calidad de un workflow de reservas: distinguir una reserva nueva de una cancelación — porque tu workflow tiene que reaccionar muy distinto a cada una.

Lo que vas a aprender

Al terminar esta cápsula serás capaz de:

✅ Configurar el Calendly Trigger para recibir webhooks
✅ Elegir a qué eventos suscribirte: reservas, cancelaciones
✅ Distinguir una reserva nueva de una cancelación en el workflow
✅ Entender por qué el webhook es tiempo real (y qué necesita)
✅ Activar y probar el webhook con una reserva real
✅ Evitar el doble procesamiento de una misma reserva

Recordatorio de G2: webhook = push, no pull

En G2-M01 viste la diferencia entre polling (tu workflow pregunta cada cierto tiempo) y webhook/push (el servicio externo te avisa en el momento). El Gmail Trigger del Módulo 2 era polling — tenía retraso. El Slack Trigger del Módulo 4 era tiempo real. El Calendly Trigger es tiempo real, como Slack.

Cuando alguien termina de reservar en tu Calendly, Calendly envía inmediatamente un aviso (el webhook) a una URL de tu n8n. No hay retraso de "esperar al siguiente sondeo" — el workflow se enciende casi al instante.

Esto tiene un requisito de setup, igual que con Slack: Calendly tiene que poder alcanzar tu n8n. Tu instancia necesita una URL pública. En n8n Cloud ya lo está; en self-hosted, tu n8n debe ser accesible desde internet. Sin eso, el webhook no llega.

Configurar el Calendly Trigger

El Calendly Trigger va al inicio del workflow (es un trigger).

Configuración base

Credential: la credencial de Calendly (cápsula 02)
Events: a qué eventos suscribirte — la decisión clave (abajo)
n8n genera la URL del webhook y la registra en Calendly automáticamente — no tienes que ir a configurar nada a mano en Calendly (a diferencia de algunos otros servicios)

Eso es una comodidad del Calendly Trigger: cuando activas el workflow, n8n se encarga de "decirle" a Calendly "avísame a esta URL". Cuando lo desactivas, lo limpia. Tú solo eliges los eventos.

A qué eventos suscribirte

Aquí está la decisión central. El Calendly Trigger te deja elegir, y los dos que importan son:

Evento	Se dispara cuando...
invitee.created	Alguien reserva una cita — una reserva nueva
invitee.canceled	Alguien cancela una cita previamente reservada

Recuerda la cápsula 03: el webhook habla de invitees dentro de eventos agendados — invitee.created = "un invitee acaba de crear su reserva", invitee.canceled = "un invitee canceló". Tiene sentido: lo accionable para tu negocio es "alguien reservó" o "alguien canceló".

Puedes suscribirte a uno o a ambos. La recomendación: suscríbete a ambos — porque un sistema de reservas serio tiene que reaccionar tanto a las altas como a las bajas. Una cancelación que tu workflow ignora deja una cita "fantasma" en tu CRM y un follow-up que se manda para una reunión que ya no existe.

Distinguir reserva de cancelación

Si te suscribes a ambos eventos, el mismo workflow recibe los dos — y tiene que reaccionar muy distinto a cada uno:

Llega...	El workflow debería...
invitee.created (reserva)	Confirmar, registrar en CRM, avisar al equipo, programar follow-up
invitee.canceled (cancelación)	Marcar la cita como cancelada, cancelar el follow-up, quizás avisar "se liberó este horario"

Cómo distinguirlos en el workflow

El payload del webhook incluye qué tipo de evento es. Justo después del trigger, un nodo IF o Switch que separa las dos ramas:

Calendly Trigger (invitee.created + invitee.canceled)
   │
   ▼
Switch: ¿qué tipo de evento es?
   │
   ┌──────────────┴──────────────┐
   ▼ invitee.created             ▼ invitee.canceled
 [rama de reserva nueva]        [rama de cancelación]

Mira el output real del trigger para ver exactamente en qué campo viene el tipo de evento — como en todos los módulos, no lo adivines. Pero el principio es claro: un workflow que recibe ambos eventos necesita separarlos de inmediato.

Activar y probar

Activar

El Calendly Trigger, como todo trigger, solo funciona con el workflow activo. Mientras desarrollas, n8n te deja "escuchar" en modo prueba; para producción, el workflow tiene que estar en Active.

Probar

La forma de probar es hacer una reserva real:

Activa el workflow (o ponlo en modo escucha de prueba)
Entra a tu propia página de Calendly y reserva una cita (puedes reservarte a ti mismo)
En segundos, el workflow debería dispararse con los datos de esa reserva
Para probar la cancelación: cancela esa cita de prueba y verifica que el workflow se dispara de nuevo, esta vez por invitee.canceled

No hay forma de "simular" un webhook tan fielmente como hacer una reserva real. Reserva, observa, cancela, observa. Es la mejor prueba.

El doble procesamiento

Un riesgo a tener presente, aunque con webhooks es menos común que con polling: que la misma reserva se procese dos veces.

Puede pasar si Calendly reenvía un webhook (por un timeout de red), o si pruebas el workflow varias veces sobre la misma reserva. Las defensas, que ya conoces:

Cada evento agendado tiene un ID único. Úsalo como clave: aplica "buscar antes de actuar" (Módulo 1) — antes de registrar la reserva en tu CRM o tu hoja, busca si ese ID ya está. Si está, no la proceses de nuevo.
Diseña idempotente: usa Create or Update en vez de Create donde puedas (lo viste en HubSpot, Módulo 6).

El mini-proyecto (cápsula 08) aplica esto.

Trampas comunes

Trampa 1: El workflow no está activo

Qué pasa: Configuras todo perfecto, haces una reserva, y nada se dispara.

Cómo evitar: El Calendly Trigger solo funciona con el workflow activo (o en modo escucha de prueba). Es lo primero que hay que verificar.

Trampa 2: Suscribirse solo a `invitee.created`

Qué pasa: El workflow procesa reservas nuevas pero ignora las cancelaciones. Quedan citas fantasma en tu CRM y follow-ups que se mandan para reuniones canceladas.

Cómo evitar: Suscríbete a ambos eventos y maneja las dos ramas. Un sistema de reservas serio reacciona a altas y bajas.

Trampa 3: No separar reserva de cancelación

Qué pasa: El workflow recibe ambos eventos pero los trata igual — entonces "confirma" una cancelación, o intenta registrar como nueva una cita que se canceló.

Cómo evitar: Un Switch/IF justo después del trigger que separe invitee.created de invitee.canceled. Reaccionan muy distinto.

Trampa 4: n8n no es accesible desde internet (self-hosted)

Qué pasa: En self-hosted, Calendly no puede entregar el webhook porque tu n8n no tiene URL pública.

Cómo evitar: Tu n8n self-hosted debe ser accesible desde internet. n8n Cloud ya lo resuelve.

Trampa 5: Construir el workflow sin ver el payload real

Qué pasa: Asumes en qué campos vienen los datos del invitee y el tipo de evento, y apuntas a campos que no existen.

Cómo evitar: Haz una reserva de prueba, mira el output real del trigger, construye sobre los nombres reales.

Ejercicio: recibe una reserva y una cancelación

Objetivo: ver el webhook en acción y separar las dos ramas.

Tu tarea

Construye un workflow: Calendly Trigger → Switch
- En el trigger: suscríbete a invitee.created e invitee.canceled
- En el Switch: una salida para cada tipo de evento
En cada salida del Switch, un nodo Set simple que marque qué pasó (action = "new booking" / action = "cancellation")
Activa el workflow (o ponlo en modo escucha de prueba)
Haz una reserva real en tu Calendly → verifica que el workflow dispara y cae en la rama invitee.created
Cancela esa cita → verifica que el workflow dispara de nuevo y cae en la rama invitee.canceled
Mira el output del trigger en ambos casos — localiza los datos del invitee y el campo que dice el tipo de evento

Checklist de éxito:

El workflow dispara al hacer una reserva real (tiempo real, sin retraso notable)
El workflow dispara también al cancelar
El Switch separa correctamente reserva de cancelación
Identificaste en el output dónde vienen los datos del invitee

Resumen y siguiente paso

El webhook de Calendly es la señal que enciende tu automatización — push, tiempo real, no polling (como el Slack Trigger)
El Calendly Trigger registra la URL del webhook en Calendly automáticamente — tú solo eliges los eventos
Los dos eventos clave: invitee.created (alguien reservó) e invitee.canceled (alguien canceló) — suscríbete a ambos
Un workflow que recibe ambos debe separarlos con un Switch/IF — reaccionan muy distinto (confirmar vs cancelar)
Requiere que Calendly alcance tu n8n — URL pública (n8n Cloud ya la tiene)
El workflow debe estar activo; pruébalo con una reserva real
Defensa contra doble procesamiento: el ID del evento agendado + "buscar antes de actuar"
5 trampas: workflow inactivo, suscribirse solo a created, no separar las ramas, n8n no accesible, no ver el payload real

Antes de avanzar deberías poder:

Configurar el Calendly Trigger con ambos eventos
Separar reserva de cancelación con un Switch
Probar el webhook con una reserva real

Lo que sigue (cápsula 05):

El webhook te entrega una reserva — pero "una reserva" es un montón de datos. La cápsula 05 te enseña a trabajar con los datos de una reserva: extraer quién reservó, su email, la hora exacta, las respuestas a tus preguntas — el insumo con el que el workflow post-reserva realmente actúa.

Recursos adicionales

n8n Calendly Trigger Docs - Configuración del trigger.
Calendly: webhooks - Los tipos de evento de webhook disponibles.
n8n Switch node Docs - Para separar reserva de cancelación.

Creado: Mayo 14, 2026 Versión: 1.0

← AnteriorEventos y Tipos de Evento Siguiente →Trabajar con los Datos de una Reserva