Módulo 7: Calendly y Agendamiento

Troubleshooting de Calendly

Siguiente →

Descripción de la cápsula

Tu workflow de Calendly funciona en la prueba. En producción aparecen los problemas que no son de lógica: un webhook que un día deja de llegar, una cancelación que el workflow no maneja bien, datos del payload que no vienen como esperabas, y el caso que casi nadie anticipa — las reprogramaciones.

Este es el manual de diagnóstico del módulo. Y tiene un sesgo claro: como Calendly es, ante todo, un módulo de webhooks, la mayoría de los problemas giran alrededor de el webhook no llega o el webhook llega pero el workflow no lo maneja bien. Si el webhook está sano y tu lógica separa bien los casos, el 90% de los problemas desaparece.

Los cuatro problemas que verás: webhooks que no llegan, el manejo de cancelaciones y reprogramaciones, datos del payload, y los límites del plan. No hay operación nueva — hay reconocimiento de síntomas.

Lo que vas a aprender

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

  • ✅ Diagnosticar por qué un webhook de Calendly no llega
  • ✅ Manejar bien las cancelaciones y reconocer las reprogramaciones
  • ✅ Resolver problemas con los datos del payload
  • ✅ Entender las limitaciones del plan de Calendly
  • ✅ Leer las situaciones de Calendly y clasificarlas rápido
  • ✅ Reconocer los casos que "no dan error" pero rompen el negocio

Problema 1: El webhook no llega

El síntoma

El workflow no se dispara cuando alguien reserva. O funcionaba y un día dejó de hacerlo.

Por qué pasa

El webhook es una cadena: Calendly tiene que poder alcanzar tu n8n, el workflow tiene que estar escuchando, la suscripción tiene que estar registrada. Si cualquier eslabón se rompe, no llega nada. Causas comunes:

  • El workflow no está activo — el Calendly Trigger solo recibe con el workflow en Active (o en modo escucha de prueba). Lo más común y lo más tonto de olvidar.
  • n8n no es accesible desde internet (self-hosted sin URL pública).
  • El plan de Calendly no incluye webhooks — recuerda la cápsula 02: en planes gratuitos, los webhooks pueden no estar disponibles.
  • La suscripción del webhook se perdió — si desactivaste y reactivaste el workflow, o cambiaste algo, la suscripción registrada en Calendly puede haber quedado en mal estado.

Las soluciones

  1. Verifica que el workflow esté activo — primer reflejo, siempre.
  2. Self-hosted: confirma que n8n es accesible desde internet.
  3. Revisa el plan — si los webhooks requieren plan de pago y el tuyo no lo incluye, ese es el techo.
  4. Re-registra la suscripción: desactivar y volver a activar el workflow hace que n8n vuelva a registrar el webhook en Calendly. A veces eso "arregla" una suscripción rota.
  5. Prueba con una reserva real — es la única prueba fiable (cápsula 04).

El webhook es una cadena de eslabones. Cuando no llega, recórrelos en orden: ¿activo? → ¿accesible? → ¿plan? → ¿suscripción?

Problema 2: Cancelaciones y reprogramaciones

El síntoma

  • El workflow procesa reservas pero las cancelaciones no tienen efecto — quedan citas "fantasma"
  • Un cliente reprogramó (cambió la hora) y tu sistema quedó con dos citas, o con la hora vieja

Por qué pasa

Cancelaciones: ya lo viste en la cápsula 04 — si solo te suscribiste a invitee.created, las cancelaciones simplemente no llegan. Y aunque lleguen, si el workflow no las separa de las reservas (Switch), no las maneja bien.

Reprogramaciones — el caso que casi nadie anticipa: cuando un cliente "reprograma" una cita en Calendly, internamente eso suele ser una cancelación de la cita vieja + una creación de la nueva. Es decir: tu webhook recibe un invitee.canceled y un invitee.created, casi seguidos. Si tu workflow no es consciente de esto, puede:

  • Mandar un correo de "tu cita fue cancelada" y uno de "tu cita está confirmada" — confuso
  • Dejar la cita vieja activa en el CRM y crear una nueva — duplicado

Las soluciones

  1. Suscríbete a ambos eventos (created y canceled) — sin esto no hay nada que hacer.
  2. Separa las ramas con un Switch (cápsula 04) y dale a la cancelación su propia lógica: marcar la cita como cancelada, cancelar los follow-ups (cápsula 06).
  3. Usa el ID del evento agendado como clave. Aplica "buscar antes de actuar": cuando llega una cancelación, busca la reserva original por su ID y márcala — no la ignores.
  4. Para reprogramaciones: acepta que llegan como cancel + create. Diseña el workflow para que sea idempotente y tolerante — que un cancel seguido de un create deje el estado correcto. El follow-up basado en el patrón "Schedule que barre" (cápsula 06) ayuda aquí: el barrido siempre mira el estado actual, así que una cita reprogramada queda con sus datos correctos.

Problema 3: Datos del payload

El síntoma

  • Expressions que apuntan a campos vacíos
  • "Funciona con algunas reservas, falla con otras"
  • Las respuestas del formulario no aparecen donde esperabas

Por qué pasa

Recuerda la cápsula 05: el payload de Calendly es anidado y rico, y la causa #1 de problemas es adivinar la estructura en vez de mirarla. Causas concretas:

  • Apuntaste a un campo asumiendo su ruta, y está anidado en otro lado.
  • Un tipo de evento tiene preguntas distintas a otro — si tu workflow procesa varios tipos de evento, las respuestas no están en las mismas posiciones.
  • Un campo opcional (un teléfono, una respuesta no obligatoria) a veces viene y a veces no — y tu mapeo no tiene valor por defecto.

Las soluciones

  1. Mira el output real — la regla de oro de la cápsula 05. No avances con rutas adivinadas.
  2. Aplana y normaliza con un Set al inicio (cápsula 05) — el resto del workflow trabaja con campos planos y predecibles.
  3. Valores por defecto para todo campo opcional — {{ $json.x || '' }}, el diseño defensivo de toda la guía.
  4. Si procesas varios tipos de evento, no asumas que sus payloads son idénticos — sobre todo las preguntas. Considera separar por tipo de evento antes de extraer respuestas.

Problema 4: Límites del plan

El síntoma

Operaciones de la API que fallan o no están disponibles; webhooks que no se pueden configurar.

Por qué pasa

Es el punto de la cápsula 02: Calendly reserva varias capacidades de integración para sus planes de pago. Los webhooks, en particular, suelen requerir plan de pago. No es un bug — es el modelo de negocio de Calendly.

Las soluciones

  1. Verifica qué incluye tu plan respecto a API y webhooks.
  2. Para aprender y construir, el trial de un plan de pago cubre el módulo completo.
  3. Cuando el negocio dependa de esto en serio, el plan de pago es parte del costo de operar — igual que pasó con n8n Cloud, HubSpot, etc. La automatización tiene un costo de herramientas; tenlo en el presupuesto.

No confundas "el plan no lo permite" con "lo configuré mal". Si una capacidad simplemente no aparece o la API la rechaza por completo, revisa el plan antes de pelear con la configuración.

Los casos que "no dan error"

Como en otros módulos, los problemas más peligrosos de Calendly no producen un error rojo:

SituaciónPor qué no da errorCómo lo detectas
Solo suscrito a createdEl workflow funciona perfecto... para reservasLas cancelaciones simplemente "no existen" para tu sistema
Reprogramación mal manejadaCada evento (cancel, create) se procesó "bien" por separadoEl cliente recibe mensajes contradictorios; hay duplicados
Follow-up a cita canceladaEl correo se envió "con éxito"El cliente recibe "¿cómo te fue?" de una reunión que canceló

Cuando "todo funciona" pero el cliente se queja o el CRM tiene incoherencias, no busques un error en los logs — busca un caso que no consideraste. Casi siempre es una cancelación o una reprogramación.

Trampas comunes

Trampa 1: Olvidar activar el workflow

Qué pasa: Todo configurado, ninguna reserva dispara nada.

Cómo evitar: El Calendly Trigger solo recibe con el workflow activo. Primer reflejo.

Trampa 2: No anticipar las reprogramaciones

Qué pasa: Un cliente reprograma, tu sistema queda con dos citas o con la hora vieja.

Cómo evitar: Una reprogramación llega como cancel + create. Diseña el workflow para tolerarlo — idempotente, basado en el ID del evento.

Trampa 3: Adivinar la estructura del payload

Qué pasa: Apuntas a campos que no existen porque no miraste el output real.

Cómo evitar: La regla de oro de la cápsula 05 — haz una reserva de prueba, mira el output, construye sobre lo real.

Trampa 4: Pelear con la configuración cuando es el plan

Qué pasa: Pasas horas intentando configurar webhooks que tu plan no incluye.

Cómo evitar: Si una capacidad no aparece del todo, revisa el plan antes de revisar tu configuración.

Trampa 5: Confiar en "se envió con éxito"

Qué pasa: El follow-up "se envió" — a una cita cancelada. No hay error, pero el negocio se vio mal.

Cómo evitar: "Éxito" significa "la acción se ejecutó", no "la acción tenía sentido". Verifica el estado de la reserva antes de actuar sobre ella.

Ejercicio: diagnostica cinco situaciones

Objetivo: practicar la clasificación rápida.

Tu tarea

Para cada situación, di (1) qué problema es y (2) el primer paso:

  1. El workflow de reservas funcionaba; hoy no dispara con ninguna reserva nueva.
  2. Un cliente reprogramó su cita; ahora el CRM tiene dos citas suyas, una con la hora vieja.
  3. El workflow falla al extraer el "motivo de la reunión"; funciona con reservas de un tipo de evento pero no de otro.
  4. Configuras el Calendly Trigger y la opción de webhooks ni siquiera aparece disponible.
  5. Un cliente que canceló recibió un correo de follow-up "¿cómo te fue en la reunión?".
Ver respuestas
  1. El webhook no llega (Problema 1). Primer paso: verificar que el workflow esté activo; luego revisar accesibilidad, plan y re-registrar la suscripción.
  2. Reprogramación mal manejada (Problema 2). Primer paso: reconocer que una reprogramación es cancel + create; rediseñar el workflow para que use el ID del evento y sea idempotente.
  3. Datos del payload — distintos tipos de evento (Problema 3). Primer paso: mirar el output real de ambos tipos; las preguntas no están en las mismas posiciones — separar por tipo de evento antes de extraer.
  4. Límite del plan (Problema 4). Primer paso: verificar si el plan de Calendly incluye webhooks; si no, usar el trial de un plan de pago.
  5. Follow-up a cita cancelada (caso que "no da error"). Primer paso: que el workflow de follow-up verifique el estado de la reserva antes de enviar; manejar invitee.canceled para cancelar follow-ups.

Resumen y siguiente paso

  • Calendly es un módulo de webhooks — la mayoría de los problemas son "el webhook no llega" o "llega pero el workflow no lo maneja bien"
  • El webhook no llega: recorre la cadena — ¿activo? → ¿accesible? → ¿plan? → ¿suscripción? Re-registrar (desactivar/reactivar) suele arreglar suscripciones rotas
  • Cancelaciones y reprogramaciones: suscríbete a ambos eventos; una reprogramación llega como cancel + create — diseña idempotente, basado en el ID del evento
  • Datos del payload: mira el output real, aplana con un Set, valores por defecto; distintos tipos de evento tienen payloads distintos
  • Límites del plan: los webhooks suelen requerir plan de pago — si una capacidad no aparece, revisa el plan antes que la configuración
  • Los problemas más peligrosos no dan error: solo suscrito a created, reprogramación mal manejada, follow-up a cita cancelada — "éxito" no significa "tenía sentido"
  • 5 trampas: olvidar activar, no anticipar reprogramaciones, adivinar el payload, pelear con la config cuando es el plan, confiar en "se envió con éxito"

Antes de avanzar deberías poder:

  • Diagnosticar por qué un webhook no llega
  • Explicar por qué una reprogramación es cancel + create
  • Reconocer los casos que "no dan error" pero rompen el negocio

Lo que sigue (cápsula 08):

Tienes todas las piezas del módulo: conectar, el modelo, el webhook, los datos, el follow-up, y el troubleshooting. El mini-proyecto las junta en el workflow post-reserva completo — confirmación y seguimiento — que es el patrón que toda agenda comercial necesita.

Recursos adicionales

  1. n8n Calendly Trigger Docs - Configuración y troubleshooting del trigger.
  2. Calendly: webhooks - Cómo funcionan las suscripciones de webhook.
  3. Calendly: planes y límites - Qué incluye cada plan respecto a integraciones.

Creado: Mayo 14, 2026 Versión: 1.0

← AnteriorRecordatorios y Follow-upsSiguiente →Mini-Proyecto: El Workflow Post-Reserva