Módulo 7: Calendly y Agendamiento
Trabajar con los Datos de una Reserva
Descripción de la cápsula
El webhook de la cápsula 04 te entrega "una reserva". Pero "una reserva" no es un dato — es un paquete de datos: quién reservó, su email, qué tipo de cita, la hora exacta de inicio y fin, las respuestas a las preguntas que configuraste, en qué zona horaria está el invitado. Esta cápsula te enseña a abrir ese paquete y sacar lo que tu workflow necesita.
¿Por qué merece una cápsula entera? Porque el payload de un webhook de Calendly es más anidado y más rico que los datos que has visto hasta ahora. No es una fila plana como la de Sheets. Tiene estructura: el invitado está en un lugar, la hora en otro, las respuestas en una lista aparte. Si no sabes navegar esa estructura, el workflow post-reserva entero se queda sin combustible — porque todo lo que hace (confirmar, registrar, dar seguimiento) depende de extraer bien estos datos.
La técnica no es nueva — es mirar el output real y mapear, lo que vienes haciendo desde el Módulo 1. Pero aquí se aplica al dato más estructurado de la guía.
Lo que vas a aprender
Al terminar esta cápsula serás capaz de:
- ✅ Navegar el payload de un webhook de Calendly
- ✅ Extraer los datos del invitado: nombre, email
- ✅ Extraer los datos de la cita: tipo, hora de inicio y fin
- ✅ Leer las respuestas a las preguntas del formulario de reserva
- ✅ Manejar la zona horaria del invitado
- ✅ Normalizar los datos para usarlos en el resto del workflow
La regla de oro: mira el output real primero
Antes de cualquier técnica, la regla — la misma de toda la guía, pero aquí más crítica que nunca:
No adivines la estructura del payload de Calendly. Haz una reserva de prueba, dispara el webhook, y mira el output real del trigger.
El payload de Calendly es anidado y su estructura exacta puede variar entre versiones. Lo que esta cápsula te da es el mapa conceptual — qué tipo de datos esperar y dónde tienden a estar. Pero el output real de tu trigger es la fuente de verdad. Míralo, y construye tus expressions sobre lo que ves.
El mapa del payload: qué hay dentro de una reserva
Conceptualmente, una reserva de Calendly trae estos grupos de datos:
Grupo 1: el invitado (invitee)
Quién reservó. Lo más importante:
- Nombre del invitado
- Email del invitado
- Zona horaria del invitado (en qué huso eligió la hora)
Grupo 2: la cita (el evento agendado)
Cuándo y de qué tipo:
- Hora de inicio y hora de fin
- Tipo de evento del que salió ("Llamada de descubrimiento")
- Un ID único del evento agendado — la clave para no duplicar (cápsula 04)
- A veces, un enlace a la reunión (si es virtual) o ubicación
Grupo 3: las respuestas (questions & answers)
Lo que el invitado respondió al reservar. Recuerda de la cápsula 03: el tipo de evento define preguntas ("¿de qué quieres hablar?"), y al reservar, el invitado las contesta. Esas respuestas llegan en el payload — normalmente como una lista de pares pregunta/respuesta.
Este grupo es oro para un workflow comercial: no solo sabes que Ana reservó, sabes que reservó porque quiere hablar del plan anual. Eso es lo que hace que el follow-up sea relevante y no genérico.
Extraer los datos: el patrón
Una vez que miraste el output real, el trabajo es mapear — exactamente como en el Módulo 1 (cápsula 06). El patrón típico: un nodo Set justo después del trigger (o después del Switch de la cápsula 04) que aplana y normaliza la reserva en campos limpios y fáciles de usar:
name = [del grupo invitado]
email = [del grupo invitado, normalizado a minúsculas]
invitee_timezone = [del grupo invitado]
start_time = [del grupo cita]
end_time = [del grupo cita]
event_type = [del grupo cita]
event_id = [del grupo cita — la clave única]
Después de ese Set, el resto del workflow trabaja con datos planos y predecibles — no tiene que volver a navegar la estructura anidada cada vez.
Esto es diseño defensivo (Módulo 1): aplanas y normalizas una vez, al principio, y el resto del workflow se simplifica. Email en minúsculas, valores por defecto para lo opcional — lo de siempre.
Las respuestas: el grupo más útil y el más incómodo
Las respuestas a las preguntas (Grupo 3) suelen llegar como una lista de objetos pregunta/respuesta, algo conceptualmente como:
[
{ question: "¿De qué quieres hablar?", answer: "Plan anual" },
{ question: "¿Tamaño de tu empresa?", answer: "10-50" }
]
Eso es más incómodo de usar que un campo plano, porque tienes que buscar dentro de la lista la respuesta que te interesa. Opciones:
- Si solo hay una o dos preguntas, puedes referenciarlas por su posición en la lista
- Si necesitas algo más robusto, buscar por el texto de la pregunta
No te compliques de más. Mira tu payload real: cuántas preguntas tienes y en qué orden llegan. Para la mayoría de los casos (1-3 preguntas fijas), referenciarlas por posición es suficiente. El procesamiento de listas más sofisticado es territorio de G4 (Data Handling).
La zona horaria del invitado
Un detalle propio del scheduling. El invitado eligió su hora en su zona horaria — que puede no ser la tuya. Calendly maneja esto bien internamente, pero tu workflow debe ser consciente:
- La hora de inicio/fin en el payload viene normalmente en un formato estándar (ISO 8601, a menudo en UTC o con la zona indicada) — no es ambigua.
- La zona del invitado viene como dato aparte — útil si vas a mostrarle la hora "en su hora" en un correo de confirmación, o si tu equipo necesita saber desde dónde se conecta.
Recuerda el Módulo 3 (Calendar, cápsula 06): una hora sin zona no significa nada. La buena noticia con Calendly es que el payload trae las horas bien formadas — no tienes que adivinar la zona como podías tener que hacer creando eventos a mano. Solo tienes que respetar el formato que llega y, si lo muestras en un correo, formatearlo conscientemente.
Trampas comunes
Trampa 1: Adivinar la estructura en vez de mirarla
Qué pasa: Asumes en qué campo viene el email del invitado, apuntas a $json.email, y está en otro lado anidado. Medio workflow apunta a campos vacíos.
Cómo evitar: Haz una reserva de prueba, mira el output real, construye sobre lo que ves. La regla de oro de la cápsula.
Trampa 2: Navegar la estructura anidada en cada nodo
Qué pasa: Cada nodo del workflow vuelve a bucear en el payload anidado para sacar el email. Frágil y repetitivo.
Cómo evitar: Aplana y normaliza una vez con un Set al principio. El resto del workflow trabaja con campos planos.
Trampa 3: Pelear con las respuestas como si fueran campos planos
Qué pasa: Esperas que "¿de qué quieres hablar?" sea un campo directo, pero viene dentro de una lista de preguntas/respuestas.
Cómo evitar: Las respuestas son una lista. Mira tu payload, cuenta tus preguntas, y extráelas por posición (simple) o por texto de la pregunta (robusto).
Trampa 4: Ignorar la zona horaria del invitado
Qué pasa: Mandas un correo de confirmación con la hora "a las 10:00" sin aclarar la zona, y el invitado (en otra zona) se confunde.
Cómo evitar: Si muestras la hora al invitado, hazlo en su zona o indica la zona explícitamente. El payload trae la zona del invitado — úsala.
Trampa 5: No guardar el ID del evento agendado
Qué pasa: Procesas la reserva pero no extraes su ID único. Luego, cuando llega la cancelación (cápsula 04), no puedes relacionarla con la reserva original.
Cómo evitar: Extrae y guarda el event_id siempre — es la clave que conecta una reserva con su futura cancelación y evita duplicados.
Ejercicio: aplana una reserva
Objetivo: practicar la extracción de datos de un payload real de Calendly.
Preparación
Necesitas el output real de un webhook de Calendly. Si guardaste la ejecución del ejercicio de la cápsula 04, úsala; si no, haz otra reserva de prueba con el workflow en escucha.
Tu tarea
- Con el output real del trigger a la vista, identifica dónde está cada cosa: nombre del invitado, su email, su zona horaria, hora de inicio, hora de fin, tipo de cita, el ID del evento agendado, y las respuestas a tus preguntas.
- Construye un nodo Set después del trigger que aplane todo eso en campos planos:
name,email(normalizado a minúsculas),invitee_timezone,start_time,end_time,event_type,event_id. - Si tu tipo de evento tiene preguntas, extrae también al menos una respuesta a un campo plano (
reason, por ejemplo). - Verifica que después del Set tienes un objeto plano y limpio — el insumo listo para el resto del workflow.
Ver pistas
- El paso 1 es el más importante: no avances hasta tener claro dónde está cada dato en el payload de tu trigger.
- En el 2, normaliza el email:
{{ $json[...].toLowerCase().trim() }}— la ruta exacta depende de tu payload. - En el 3, si las respuestas son una lista de 1-2 elementos, referenciar por posición es suficiente.
- El resultado: un Set con ~8 campos planos. Eso es lo que el mini-proyecto (cápsula 08) consume.
Resumen y siguiente paso
- "Una reserva" no es un dato — es un paquete anidado: invitado, cita, respuestas, zona horaria
- Regla de oro: no adivines la estructura — haz una reserva de prueba y mira el output real del trigger
- Tres grupos de datos: el invitado (nombre, email, zona), la cita (inicio, fin, tipo, ID único), las respuestas (lista de pregunta/respuesta)
- El patrón: un Set que aplana y normaliza la reserva en campos planos una vez — el resto del workflow trabaja con eso
- Las respuestas son el grupo más útil (hacen el follow-up relevante) y el más incómodo (vienen en lista)
- El payload trae las horas bien formadas — respeta el formato; usa la zona del invitado si le muestras la hora
- Extrae siempre el ID del evento agendado — conecta la reserva con su futura cancelación
- 5 trampas: adivinar la estructura, navegar lo anidado en cada nodo, pelear con las respuestas como campos planos, ignorar la zona del invitado, no guardar el ID
Antes de avanzar deberías poder:
- Navegar el payload de un webhook de Calendly
- Aplanar una reserva en campos planos con un Set
- Extraer al menos una respuesta del formulario de reserva
Lo que sigue (cápsula 06):
Ya sabes recibir la reserva (cápsula 04) y leer sus datos (esta cápsula). La cápsula 06 cubre qué hacer con ella a lo largo del tiempo: recordatorios y follow-ups — el seguimiento que convierte una reserva en una relación, no solo en una cita en el calendario.
Recursos adicionales
- n8n Calendly Trigger Docs - El payload que entrega el trigger.
- n8n Set node Docs - Para aplanar y normalizar el payload.
- Calendly API: invitees - El modelo de datos del invitado y sus respuestas.
Creado: Mayo 14, 2026 Versión: 1.0