Get Products (GET /products) – quando Booking.com configura a sua conexão, e sempre que atualiza os seus anúncios, lê todos os produtos ativados na conexão, com as respetivas opções e unidades (tipos de bilhete, como Adulto ou Criança).

Get Product (GET /products/{productId}) – Booking.com volta a ler um único produto para obter alterações às suas opções, unidades, prazos limite de reserva e definições.

Mapeamento do lado de Booking.com – Booking.com associa cada opção e unidade Ventrata à sua própria listagem e aos seus tipos de bilhete. O seu gestor de conta em Booking.com faz isto por si, ou pode fazê-lo no portal próprio de Booking.com, se Booking.com disponibilizar um. Não precisa de partilhar uma chave API: Booking.com acede à conexão de forma segura a partir da Ventrata.

Booking.com lê a sua lista completa de produtos aproximadamente a cada 3 horas.

Volta a ler cada produto aproximadamente a cada 2 horas.

Capability ventrata/content – Booking.com adiciona-a ao cabeçalho Octo-Capabilities, para que Get Products (GET /products) e Get Product (GET /products/{productId}) devolvam também o conteúdo dos seus produtos: títulos, descrições, destaques, inclusões e exclusões, imagens, perguntas frequentes, instruções de resgate e localização.

Booking.com não tem nenhuma interface para os fornecedores editarem conteúdo, por isso o que definir na Ventrata é o que Booking.com mostra.

Booking.com verifica o conteúdo face às suas diretrizes e requisitos mínimos e arquiva ou retira do ar os produtos que não os cumprem, por exemplo com uma descrição vazia ou um Google Place ID desatualizado.

Booking.com volta a ler os seus produtos a cada poucas horas, e as alterações de conteúdo aparecem normalmente em cerca de 24 horas.

As imagens são sincronizadas por URL, por isso uma imagem substituída tem de ser carregada de novo na Ventrata.

Availability Check (POST /availability) – Booking.com envia um produto, uma opção e uma data ou intervalo de datas. A Ventrata responde com cada dia ou horário reservável, o respetivo estado (AVAILABLE, LIMITED, SOLD_OUT, CLOSED ou FREESALE), as vagas restantes, o prazo limite de reserva e um availabilityId, de que Booking.com precisa para reservar esse horário.

Verificação no momento da reserva – quando um cliente reserva, a Ventrata volta a verificar a capacidade antes de criar a reserva, pelo que Booking.com não pode fazer overbooking num horário que acabou de esgotar, mesmo que a disponibilidade que tem guardada esteja ligeiramente desatualizada.

Availability Check: Booking.com verifica os seus produtos 24 horas por dia, começando normalmente cerca de 6 meses antes e abrangendo 10 dias por pedido; consulta até cerca de um ano de antecedência e volta a verificar o mesmo produto e as mesmas datas aproximadamente a cada 30 minutos.

As consultas estão distribuídas de forma uniforme ao longo do dia, o que aponta para uma sincronização agendada em segundo plano e não para pesquisas de clientes em tempo real.

Capability octo/pricing – Booking.com adiciona sempre octo/pricing ao cabeçalho Octo-Capabilities dos seus pedidos, pelo que cada verificação de disponibilidade inclui os seus preços.

Availability Check (POST /availability) – com os preços ativados, cada dia ou horário é devolvido com o seu preço por unidade (tipo de bilhete): o preço retail que o cliente paga e o preço net que fatura a Booking.com, ambos a partir dos preços do revendedor na Ventrata (venda ao público e por grosso/comissão).

Preços de grupo – quando Booking.com envia também quantas pessoas de cada tipo de unidade estão a reservar, a Ventrata calcula o preço desse grupo exato. Isto é importante para tarifas Booking Size e outros preços de grupo.

Booking Reservation (POST /bookings) e Booking Confirmation (POST /bookings/{uuid}/confirm) – a reserva é devolvida com o preço final de venda ao público e o preço líquido, pelo que a reserva na Ventrata regista sempre o preço a que foi vendida.

Booking.com pede octo/pricing em todas as suas consultas de disponibilidade, pelo que vende aos seus preços da Ventrata.

Booking.com não envia o número de pessoas por tipo de unidade, pelo que os preços são devolvidos por pessoa e os preços de grupo, como as tarifas Booking Size, podem não ser apresentados corretamente em Booking.com.

Capability octo/offers: com ela, a Ventrata aplica as suas promoções elegíveis aos preços de disponibilidade e às reservas, e Booking.com também pode enviar um código promocional (offerCode).

As promoções funcionam em conjunto com os preços, pelo que também precisam de octo/pricing.

Isto abrange as promoções que cria na Ventrata (promoções iniciadas pelo fornecedor).

Booking.com pede octo/offers.

Booking.com bloqueia os lugares durante cerca de 20 minutos enquanto o cliente paga (expirationMinutes).

Uma reserva típica em Booking.com é para cerca de 3 pessoas.

É normal ver mais retenções do que reservas confirmadas: as retenções de clientes que não concluem o pagamento simplesmente expiram.

Booking.com também verifica as reservas que efetuou, com Get Booking (GET /bookings/{uuid}) de poucos em poucos minutos, por exemplo, para reconciliar os seus registos.