¿El calendario de Airbnb no se sincroniza? 7 motivos de un feed iCal caducado

El invierno pasado mi calendario de Booking.com dejó de tirar de mis bloqueos de Airbnb sin hacer ruido. Ningún error: ni correo, ni banner rojo. La importación se congeló un martes, y no lo noté hasta que un huésped de Lyon reservó una semana que yo ya tenía ocupada en Airbnb. El feed no estaba «roto» de ninguna forma que el panel admitiera. Estaba caducado, y la caducidad es el único fallo del que iCal nunca avisa.

Esta es la guía que me habría gustado tener aquella noche: el único número que dice si un feed está realmente roto, los siete motivos por los que enmudece y la solución exacta para cada uno.

Por qué iCal enmudece en vez de romperse

La sincronización iCal es un tirón, no un empuje. Cuando «conecta» Airbnb con Booking.com, ninguna de las dos plataformas abre una API en vivo a la otra. La plataforma de destino simplemente descarga una URL .ics pública a su propio ritmo —cada pocas horas— y sobrescribe sus bloqueos importados con lo que encuentre.

Ese diseño tiene un efecto secundario desagradable. Si la URL de origen deja de responder —URL incorrecta, origen caído un momento, origen que rotó su enlace—, el destino no muestra ningún fallo. Conserva los últimos datos que descargó con éxito y vuelve a intentarlo en el siguiente ciclo. Desde el panel, todo va bien. El calendario sigue mostrando bloqueos, solo que congelados en el tiempo.

Una conexión API real lanzaría un 401 o un 404 que usted vería. iCal no lanza nada. El protocolo (RFC 5545) no tiene canal de empuje ni una señal estándar de «este feed está muerto» que las grandes plataformas trasladen al anfitrión. Así que el fallo es invisible hasta que un segundo huésped reserva fechas que su otra plataforma cree libres.

El único diagnóstico que importa: la última importación

Antes de cambiar una sola URL, lea un número: ¿cuándo se importó este feed con éxito por última vez?

• Airbnb: Calendar → elija el alojamiento → Availability → Sync calendars → bajo Imported calendars, cada feed indica hace cuánto se importó.
• Booking.com: extranet → Calendar & Pricing → Sync calendars → la sección de importación lista cada feed conectado con su última hora de sincronización.

Ahora léalo así:

Esa marca de tiempo lo es todo. Nueve de cada diez pánicos de «mi calendario no se sincroniza» son, o bien un feed sano dentro de su ventana normal, o bien un feed muerto desde hace días al que nadie le miró la fecha.

Los siete motivos por los que un feed caduca, y la solución de cada uno

1. La URL de origen se reinició (la causa número uno)

Síntoma: el feed funcionaba; la última importación es ahora de hace días o «nunca». Causa: alguien pulsó Reset URL en la plataforma de origen —usted, un co-anfitrión, o usted mismo tras un susto por un enlace filtrado—. El reinicio mata la URL antigua al instante, y el destino sigue sosteniendo la retirada. Cada petición desde entonces ha fallado en silencio con un 404.

Solución: copie la URL de exportación actual del origen, borre la importación muerta en el destino y vuelva a añadirla. Luego pruebe la URL (vea la comprobación del motivo 5). Trate la URL de exportación como una contraseña: reiniciarla tras una filtración es lo correcto, pero el mismo día debe actualizarla en todas partes donde se importe.

2. Está dentro de la ventana normal de refresco (falsa alarma)

Síntoma: bloqueó fechas en Airbnb hace 40 minutos y Booking.com las sigue mostrando libres. Causa: nada. Booking.com tira cada 2-6 horas; simplemente aún no ha lanzado su siguiente ciclo.

Solución: espere. Si han pasado más de 6 horas en Booking.com o más de 4 en Airbnb, entonces trátelo como real y baje por la lista. Es la falsa alarma más común: el anfitrión vigila el destino diez minutos y concluye que la sincronización está rota, cuando solo duerme hasta el siguiente sondeo.

3. La plataforma descartó el feed en silencio tras fallos repetidos

Síntoma: el feed funcionaba, luego el origen estuvo caído un día (mantenimiento, una URL rotada que ya corrigió) y ahora no se recupera, aunque la URL vuelve a estar viva. Causa: tras varias peticiones fallidas seguidas, algunas plataformas dejan de sondear un feed por completo y no lo reactivan solas. El contador de fallos se enganchó.

Solución: borre la importación y vuelva a añadir exactamente la misma URL. Eso reinicia el contador y la plataforma empieza de cero. Una URL viva que sigue sin sincronizar tras 24 horas es casi siempre este caso.

4. iCal está desactivado en la cuenta de origen

Síntoma: no hay ninguna URL de exportación que copiar, o el panel Sync calendars desapareció del origen. Causa: las cuentas con contrato de channel manager o socio de API tienen iCal apagado por diseño: la plataforma asume la API como fuente de verdad. Algunos tipos de propiedad de Booking.com (hoteles clásicos, frente a alquileres vacacionales) nunca exponen iCal.

Solución: si firmó un acuerdo de socio/API, es lo esperado: su sincronización va por la API, no por iCal. Si no firmó nada e iCal simplemente desapareció, contacte con el soporte de socios; para alquileres vacacionales lo reactivan.

5. El feed se importa, pero los bloqueos no aparecen

Síntoma: la última importación es reciente —de hace minutos—, pero las fechas siguen libres. Causa: la importación tuvo éxito, pero los eventos no llevan estado de ocupado, o el importador solo lee eventos DATE de día completo y el origen envió eventos con hora. Raro con Airbnb y Booking.com (envían bloqueos de día completo limpios) y común con feeds caseros u oscuros.

Solución: abra el .ics en un editor de texto y mire un VEVENT. Quiere bloqueos de día completo del estilo DTSTART;VALUE=DATE:20260714 sobre las fechas esperadas. Esta es la prueba rápida de navegador para cualquier URL iCal:

1. Pegue la URL de exportación en la barra de direcciones del navegador.
2. Un feed vivo descarga un archivo .ics o muestra texto plano que empieza por BEGIN:VCALENDAR.
3. Una página de error HTML, una pantalla de inicio de sesión o una respuesta vacía significan que la URL está muerta: vuelva al motivo 1.

6. Un desfase de zona horaria corre cada bloqueo un día

Síntoma: los bloqueos se importan, pero caen un día desplazados —día de salida bloqueado, día de entrada libre, o al revés—. Causa: un feed que envía eventos con hora y con un TZID que el destino lee en UTC puede pasar un bloqueo de la medianoche. Un inicio a las 23:00 hora local se convierte en el día siguiente en UTC.

Solución: prefiera bloqueos de día completo (VALUE=DATE) a los que llevan hora. Las grandes plataformas ya lo hacen; si el feed es suyo (autoalojado, exportación a medida), envíe fechas, no fecha-hora. Si está obligado a consumir un feed con hora, el desfase de exactamente un día es la pista: no pierda una hora culpando a la URL.

7. Llegó al tope de huecos de importación

Síntoma: no puede añadir otro calendario importado, o el más nuevo se ignora en silencio. Causa: la mayoría de plataformas limitan los feeds importados a unos cinco por alojamiento. Publique en Airbnb, Booking.com, Vrbo, Expedia y una web directa, y los huecos se agotan rápido cuando cada plataforma debe importar todas las demás.

Solución: pliegue la malla en estrella. En vez de que N plataformas importen cada una a otras N−1, ponga a correr un feed intermedio por plataforma: cada plataforma importa el hub, el hub importa cada plataforma. Dos plataformas son cuatro URL directas; el hub las deja en dos. Es también la razón por la que la importación cruzada directa deja de escalar pasadas dos plataformas; más detalles en evitar reservas duplicadas.

Cuando el hueco es de la plataforma, no suyo

Aquí va la parte honesta. Incluso con las siete causas descartadas y cada feed sano, el propio sondeo de la plataforma de destino es el suelo. Booking.com tira cada 2-6 horas, y eso no lo cambia usted.

Una capa intermedia resuelve la mitad del problema. Una herramienta de código abierto como RentTools —o un cron que escriba usted mismo— consulta los feeds de origen cada 10 minutos, así que su hub se entera de una nueva reserva de Airbnb en diez minutos en vez de en horas. Lo que no puede hacer es obligar a Booking.com a tirar del hub más rápido de lo que Booking.com quiere. Lo único que bate el ciclo de sondeo por completo es la conexión por API en tiempo real, que Airbnb y Booking.com solo venden a PMS certificados por 100-300 $ al mes.

Para uno a tres alojamientos, no pierda el sueño por la ventana de refresco. Las causas de caducidad de arriba —una URL reiniciada que nadie actualizó, un feed que la plataforma descartó en silencio— provocan a pequeña escala muchas más reservas duplicadas que el sondeo de 2-6 horas. Si quiere la configuración completa en vez del diagnóstico, empiece por sincronizar gratis los calendarios de Airbnb y Booking.com.

Una opinión con criterio

Deje de ver la ventana de refresco como el enemigo. El problema espectacular de «iCal no es en tiempo real» provoca a pequeña escala menos reservas duplicadas que lo aburrido: una URL que alguien reinició y olvidó actualizar, un feed que la plataforma dejó de sondear sin avisar. Ambos son invisibles mientras no mire la última importación, así que mírela. Una vez por semana, abra cada feed importado y lea una fecha. Un hábito de veinte segundos que atrapa los fallos silenciosos que el panel está encantado de ocultarle.