Get Products (GET /products) – lorsque Booking.com configure votre connexion, puis chaque fois qu'il actualise ses fiches, il lit chaque produit activé sur la connexion, avec ses options et ses unités (types de billets comme Adulte ou Enfant).

Get Product (GET /products/{productId}) – Booking.com relit un produit précis pour prendre en compte les modifications de ses options, unités, délais limites de réservation et paramètres.

Mappage du côté de Booking.com – Booking.com associe chaque option et unité Ventrata à sa propre fiche et à ses propres types de billets. Votre gestionnaire de compte chez Booking.com s'en charge pour vous, ou vous le faites dans le portail de Booking.com si Booking.com en propose un. Vous n'avez pas besoin de partager de clé API : Booking.com accède à la connexion de manière sécurisée depuis Ventrata.

Booking.com lit votre liste complète de produits environ toutes les 3 heures.

Il relit chaque produit environ toutes les 2 heures.

Capability ventrata/content – Booking.com l'ajoute à l'en-tête Octo-Capabilities, de sorte que Get Products (GET /products) et Get Product (GET /products/{productId}) renvoient aussi le contenu de vos produits : titres, descriptions, points forts, inclusions et exclusions, images, FAQ, instructions de validation et emplacement.

Booking.com n'offre aux fournisseurs aucune interface pour modifier le contenu : ce que vous définissez dans Ventrata est donc ce que Booking.com affiche.

Booking.com vérifie le contenu au regard de ses consignes et exigences minimales, et archive ou met hors ligne les produits non conformes, par exemple ceux dont la description est vide ou dont le Google Place ID est obsolète.

Booking.com relit vos produits à quelques heures d'intervalle, et les modifications de contenu apparaissent généralement sous environ 24 heures.

Les images sont synchronisées par URL : une image remplacée nécessite donc un nouveau téléchargement dans Ventrata.

Availability Check (POST /availability) – Booking.com envoie un produit, une option et une date ou une plage de dates. Ventrata répond avec chaque jour ou créneau réservable, son statut (AVAILABLE, LIMITED, SOLD_OUT, CLOSED ou FREESALE), les places restantes, le délai limite de réservation et un availabilityId, dont Booking.com a besoin pour réserver ce créneau.

Vérification à la réservation – lorsqu'un client réserve, Ventrata vérifie à nouveau la capacité avant de créer la réservation : Booking.com ne peut donc pas surréserver un créneau qui vient d'être complet, même si les disponibilités qu'il a enregistrées sont légèrement obsolètes.

Availability Check : Booking.com vérifie vos produits 24 h/24, en commençant généralement environ 6 mois à l'avance et en couvrant 10 jours par requête ; il consulte les dates jusqu'à environ un an à l'avance et revérifie le même produit et les mêmes dates environ toutes les 30 minutes.

Les vérifications sont réparties uniformément sur 24 heures, ce qui indique une synchronisation planifiée en arrière-plan plutôt que des recherches de clients en direct.

Capability octo/pricing – Booking.com ajoute toujours octo/pricing à l'en-tête Octo-Capabilities de ses requêtes, de sorte que chaque vérification des disponibilités inclut vos prix.

Availability Check (POST /availability) – lorsque la tarification est activée, chaque jour ou créneau est renvoyé avec votre prix par unité (type de billet) : le prix public payé par le client et le prix net que vous facturez à Booking.com, tous deux issus de la tarification du revendeur dans Ventrata (prix public et prix de gros/commission).

Prix de groupe – lorsque Booking.com envoie aussi le nombre de personnes réservant pour chaque type d'unité, Ventrata calcule le prix exact pour ce groupe. C'est important pour les tarifs selon la taille de la réservation (Booking Size) et les autres tarifs de groupe.

Booking Reservation (POST /bookings) et Booking Confirmation (POST /bookings/{uuid}/confirm) – la réservation est renvoyée avec son prix public et son prix net définitifs : la réservation dans Ventrata enregistre donc toujours le prix auquel elle a été vendue.

Booking.com demande octo/pricing pour toutes ses consultations de disponibilités : il vend donc à vos prix Ventrata.

Booking.com n'envoie pas le nombre de personnes par type d'unité : les prix sont donc renvoyés par personne, et les tarifs de groupe, comme les tarifs selon la taille de la réservation (Booking Size), peuvent ne pas s'afficher correctement sur Booking.com.

Capability octo/offers : grâce à elle, Ventrata applique vos promotions éligibles aux prix des disponibilités et aux réservations, et Booking.com peut aussi envoyer un code promo (offerCode).

Les promotions fonctionnent avec la tarification ; elles nécessitent donc aussi octo/pricing.

Cela concerne les promotions que vous créez dans Ventrata (promotions à l'initiative du fournisseur).

Booking.com demande octo/offers.

Booking.com bloque les places pendant environ 20 minutes, le temps que le client paie (expirationMinutes).

Une réservation Booking.com typique concerne environ 3 personnes.

Il est normal de voir plus de blocages que de réservations confirmées : les blocages des clients qui ne terminent pas leur paiement expirent simplement.

Booking.com vérifie aussi les réservations qu'il a effectuées, avec Get Booking (GET /bookings/{uuid}) à quelques minutes d'intervalle, par exemple pour rapprocher ses données.