Get Products (GET /products) – quando Trip.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}) – Trip.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 Trip.com – Trip.com associa cada opção e unidade da Ventrata ao seu próprio anúncio e aos seus tipos de bilhete. O seu gestor de conta em Trip.com faz isto por si, ou pode fazê-lo no portal de Trip.com, se Trip.com disponibilizar um. Só precisa de partilhar a chave API da conexão.

Trip.com lê a sua lista completa de produtos de poucos em poucos dias.

Volta a ler cada produto aproximadamente a cada 10 minutos.

Availability Check (POST /availability) – Trip.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 Trip.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 Trip.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: Trip.com verifica os seus produtos 24 horas por dia, normalmente a partir de hoje e abrangendo cerca de 3 meses por pedido, consulta até cerca de 3 meses de antecedência e volta a verificar o mesmo produto e as mesmas datas aproximadamente a cada 40 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 – Trip.com pede preços adicionando octo/pricing ao cabeçalho Octo-Capabilities dos seus pedidos. Sem ela, a Ventrata envia a disponibilidade sem quaisquer 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 Trip.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 Trip.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.

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

Trip.com envia o número de pessoas por tipo de unidade, para que os preços de grupo sejam calculados com base na reserva efetiva.

Trip.com não define um tempo de retenção, pelo que se aplica o tempo de retenção predefinido.

Uma reserva típica em Trip.com é para cerca de 2 pessoas.

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

Trip.com também verifica as reservas que efetuou, com Get Booking (GET /bookings/{uuid}) aproximadamente a cada 5 horas, por exemplo, para reconciliar os seus registos.