Get Products (GET /products): cuando Booking.com configura su conexión, y cada vez que actualiza sus anuncios, lee todos los productos habilitados en la conexión, con sus opciones y unidades (tipos de entrada, como Adulto o Niño).

Get Product (GET /products/{productId}): Booking.com vuelve a leer un producto concreto para recoger los cambios en sus opciones, unidades, plazos límite de reserva y ajustes.

Mapeo por parte de Booking.com: Booking.com vincula cada opción y unidad de Ventrata con su propia ficha y sus tipos de entrada. Su gestor de cuenta en Booking.com lo hace por usted, o lo hace usted en el portal propio de Booking.com si Booking.com ofrece uno. No necesita compartir una clave API: Booking.com accede a la conexión de forma segura desde Ventrata.

Booking.com lee su lista completa de productos aproximadamente cada 3 horas.

Vuelve a leer cada producto aproximadamente cada 2 horas.

Capability ventrata/content: Booking.com la añade a la cabecera Octo-Capabilities, de modo que Get Products (GET /products) y Get Product (GET /products/{productId}) también devuelven el contenido de sus productos: títulos, descripciones, puntos destacados, inclusiones y exclusiones, imágenes, preguntas frecuentes, instrucciones de canje y ubicación.

Booking.com no tiene ninguna interfaz para que los proveedores editen el contenido, así que lo que configure en Ventrata es lo que muestra Booking.com.

Booking.com compara el contenido con sus directrices y requisitos mínimos, y archiva o desactiva los productos que no los cumplen, por ejemplo, los que tienen la descripción vacía o un Google Place ID desactualizado.

Booking.com vuelve a leer sus productos cada pocas horas, y los cambios de contenido suelen mostrarse en unas 24 horas.

Las imágenes se sincronizan por URL, por lo que una imagen sustituida requiere una nueva subida en Ventrata.

Availability Check (POST /availability): Booking.com envía un producto, una opción y una fecha o un intervalo de fechas. Ventrata responde con cada día o franja horaria reservable, su estado (AVAILABLE, LIMITED, SOLD_OUT, CLOSED o FREESALE), las plazas restantes, el plazo límite de reserva y un availabilityId, que Booking.com necesita para reservar esa franja.

Comprobación al reservar: cuando un cliente reserva, Ventrata vuelve a comprobar el aforo antes de crear la reserva, de modo que Booking.com no puede sobrevender una franja que acaba de agotarse, aunque la disponibilidad que tiene almacenada esté ligeramente desactualizada.

Availability Check: Booking.com consulta sus productos las 24 horas del día, normalmente empezando unos 6 meses antes y abarcando 10 días por solicitud; consulta hasta aproximadamente un año vista y vuelve a comprobar el mismo producto y las mismas fechas cada 30 minutos aproximadamente.

Las consultas se reparten de forma uniforme a lo largo del día, lo que apunta a una sincronización programada en segundo plano más que a búsquedas de clientes en tiempo real.

Capability octo/pricing: Booking.com siempre añade octo/pricing a la cabecera Octo-Capabilities de sus solicitudes, de modo que cada consulta de disponibilidad incluye sus precios.

Availability Check (POST /availability): con los precios activados, cada día o franja horaria se devuelve con su precio por unidad (tipo de entrada): el precio de venta al público que paga el cliente y el precio neto que usted factura a Booking.com, ambos a partir de los precios del revendedor en Ventrata (de venta al público y mayoristas o de comisión).

Precios para grupos: cuando Booking.com también envía cuántas personas de cada tipo de unidad reservan, Ventrata calcula el precio de ese grupo exacto. Esto es importante para las tarifas por tamaño de la reserva (Booking Size) y otros precios para grupos.

Booking Reservation (POST /bookings) y Booking Confirmation (POST /bookings/{uuid}/confirm): la reserva se devuelve con su precio final de venta al público y neto, de modo que la reserva en Ventrata siempre registra el precio al que se vendió.

Booking.com solicita octo/pricing en todas sus consultas de disponibilidad, por lo que vende con sus precios de Ventrata.

Booking.com no envía el número de personas por tipo de unidad, por lo que los precios se devuelven por persona, y los precios para grupos, como las tarifas por tamaño de la reserva (Booking Size), podrían no mostrarse correctamente en Booking.com.

Capability octo/offers: con ella, Ventrata aplica a los precios de disponibilidad y a las reservas las promociones que correspondan, y Booking.com también puede enviar un código promocional (offerCode).

Las promociones funcionan junto con los precios, por lo que también necesitan octo/pricing.

Esto abarca las promociones que usted crea en Ventrata (promociones iniciadas por el proveedor).

Booking.com solicita octo/offers.

Booking.com retiene las plazas durante unos 20 minutos mientras el cliente paga (expirationMinutes).

Una reserva típica de Booking.com es para unas 3 personas.

Es normal ver más retenciones que reservas confirmadas: las retenciones de clientes que no terminan de pagar simplemente caducan.

Booking.com también comprueba las reservas que ha realizado, con Get Booking (GET /bookings/{uuid}) cada pocos minutos, por ejemplo para conciliar sus registros.