n8n Google Calendar: comprueba la disponibilidad antes de reservar una reunión
Crea un paso de comprobación de disponibilidad en n8n Google Calendar que bloquea horarios duplicados y solo crea eventos si el horario está libre.
Comprobado con las fuentes citadas el .
Qué vas a construir: el ejercicio de comprobación de disponibilidad
Este es un ejercicio editorial, no un caso de estudio publicado: una construcción práctica que puedes probar tú mismo dentro de tu propia instancia de n8n. El objetivo es un paso pequeño pero real de comprobación de disponibilidad en n8n Google Calendar: un workflow que recibe una solicitud de reserva, confirma si el horario solicitado está realmente libre y solo crea un evento de calendario cuando lo está. El nodo de Google Calendar de n8n incluye una operación dedicada, Calendar Availability, creada específicamente para comprobar si un horario está libre antes de que se ejecute cualquier acción de reserva.
Antes de empezar, necesitas una instancia de n8n en funcionamiento, una credencial de Google Calendar ya conectada en n8n y un calendario real sobre el que tengas permiso para hacer pruebas, ya que la operación Availability requiere elegir el calendario concreto que se va a comprobar como parámetro de configuración. Nosotros trataríamos esto primero como un pequeño workflow independiente, separado de cualquier formulario de reserva o interfaz de chatbot, de modo que el resultado de la disponibilidad se pueda ver por sí solo antes de conectar nada más.
Tres entradas determinan cada ejecución: una hora de inicio solicitada, una hora de fin solicitada y el ID del calendario que se va a comprobar. Para este ejercicio, defínelas explícitamente en lugar de depender de lo que envíe el disparador, ya que unas entradas explícitas y fijas hacen que la prueba sea repetible sobre el mismo calendario cada vez.
- Hora de inicio solicitada
- Hora de fin solicitada
- ID del calendario a comprobar
- Una zona horaria para ambas horas
Sources: Google Calendar | Nodes | n8n Docs, Calendar operations | Nodes | n8n Docs
Paso a paso: comprobación de disponibilidad en n8n Google Calendar
Una vez que las entradas están listas, el propio workflow sigue cuatro etapas, que se muestran a continuación.
La etapa uno es un disparador que captura la solicitud de reserva: un nodo Webhook o Form que recibe la hora de inicio, la hora de fin y el ID del calendario, seguido de un nodo Edit Fields para normalizarlos en un formato coherente para el siguiente paso.
La etapa dos ejecuta el propio paso de comprobación de disponibilidad en n8n Google Calendar: la operación Calendar Availability, dirigida al calendario elegido, con Output Format configurado como Availability. Con esa configuración, el nodo devuelve si algún evento existente ya se superpone con el horario solicitado, que es, en la práctica, la forma de comprobar la disponibilidad de alguien en Google Calendar desde dentro de un flujo automatizado en lugar de abrir la aplicación de calendario a mano. Por debajo, la documentación de n8n describe esta operación como una llamada a la propia consulta free/busy de Google, que informa de los datos de disponibilidad para un conjunto de calendarios.
La etapa tres se ramifica en función de ese resultado mediante un nodo IF o Switch, la forma estándar en que n8n divide un camino de workflow en varios según una condición.
La etapa cuatro actúa según la rama: en el camino libre, una operación Event Create añade la reserva, de nuevo después de elegir el calendario de destino como parámetro. En el camino ocupado, resiste la tentación de simplemente terminar el workflow; envía al solicitante un mensaje o una hora alternativa en lugar de dejar que la solicitud desaparezca en silencio.
Sources: Google Calendar | Nodes | n8n Docs, Calendar operations | Nodes | n8n Docs, Event operations | Nodes | n8n Docs, API Reference | Google Calendar | Google for Developers, Split with conditionals | Build | n8n Docs
Restricciones: zonas horarias, formato de salida y condiciones de carrera
Unas pocas restricciones determinan si este ejercicio se comporta de forma predecible. En primer lugar, las zonas horarias: configura una zona horaria explícita tanto en la hora de inicio como en la de fin solicitadas, en lugar de depender de las expresiones predeterminadas del nodo basadas en $now, de modo que la misma prueba produzca el mismo resultado cada vez que la ejecutes.
En segundo lugar, importa el formato de salida que elijas en la operación Availability. Con Output Format configurado como Availability, el nodo informa de un simple resultado de superposición en lugar de la lista de eventos subyacente, lo que responde a cómo mostrar la disponibilidad en los datos de Google Calendar sin exponer los detalles completos del evento a lo que haya disparado la comprobación. Para este ejercicio, ese simple resultado de sí o no es suficiente, ya que el siguiente paso solo necesita decidir qué rama tomar.
En tercer lugar, las condiciones de carrera: un tutorial de la comunidad de n8n sobre la creación de flujos de reserva recomienda comprobar la disponibilidad justo antes de crear el evento, manteniendo ambos pasos lo más próximos posible, para reducir la ventana en la que dos solicitudes podrían ver el mismo horario como libre a la vez. Nosotros trataríamos un resultado 'libre' de esta comprobación como una respuesta puntual en el tiempo, no como un bloqueo del horario, de modo que una versión en producción de este workflow sigue necesitando su propia protección contra reservas duplicadas; esa recomendación procede del diseño de workflow propuesto en un blog de proveedor, no de un resultado probado o medido.
- Zona horaria explícita en las horas de inicio y fin
- Output Format configurado como Availability para una ramificación simple de sí/no
- Comprobación de disponibilidad ejecutada justo antes del paso de creación del evento
Sources: Calendar operations | Nodes | n8n Docs, Publish technical n8n tutorial with full code examples and screenshots - DEV Community
Criterios de finalización, solución de problemas y una solución sugerida
La finalización de este ejercicio tiene dos pruebas: una solicitud para un horario que ya está ocupado debe bloquearse en lugar de reservarse, y una solicitud para un horario realmente libre debe terminar con la cita reservada. Esa segunda expectativa coincide con el plan de pruebas que se plantea un tutorial de la comunidad sobre workflows de reserva en n8n, aunque describe una prueba propuesta, no un resultado que alguien haya verificado de forma independiente.
Fallos comunes que vale la pena comprobar: un ID de calendario ausente o incorrecto en la operación Availability o en Event Create, ya que ambas requieren ese parámetro explícitamente; un error de la API de Google Calendar que no se capture en absoluto; y una rama ocupada que se salte el paso de enviar alguna respuesta al solicitante. El mismo tutorial de la comunidad sugiere crear un workflow de errores independiente en n8n para capturar fallos como una llamada fallida a la API del calendario. Creemos que merece la pena hacerlo incluso en un ejercicio de aprendizaje, ya que es la diferencia entre un workflow que falla de forma ruidosa y uno que falla de forma invisible.
Una solución sugerida, a grandes rasgos: un nodo disparador que captura la hora de inicio, la hora de fin, el ID del calendario y la zona horaria; una operación Calendar Availability con Output Format configurado como Availability; un nodo IF que ramifica según el resultado; una operación Event Create en el camino libre; y un paso de notificación en el camino ocupado, respaldado por un workflow de errores para todo lo que el nodo Calendar no pueda manejar. Constrúyelo, ejecuta ambos casos de prueba contra tu propio calendario, y habrás cubierto el núcleo de un verdadero paso de comprobación de disponibilidad en n8n Google Calendar en lugar de una simple demo de disparador a acción.
Sources: Publish technical n8n tutorial with full code examples and screenshots - DEV Community, Calendar operations | Nodes | n8n Docs, Event operations | Nodes | n8n Docs
