Get Products (GET /products) – lorsque visitBerlin 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}) – visitBerlin 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 visitBerlin – visitBerlin associe chaque option et unité Ventrata à ses propres fiches et types de billets. Votre gestionnaire de compte chez visitBerlin s'en charge pour vous, ou vous le faites dans le portail de visitBerlin s'il en propose un. Il vous suffit de partager la clé API de la connexion.

visitBerlin lit votre liste complète de produits environ toutes les 7 heures.

Availability Check (POST /availability) – visitBerlin 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 visitBerlin 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 : visitBerlin 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 : visitBerlin vérifie vos produits 24 h/24, en commençant généralement à la date du jour et en couvrant environ 6 mois par requête ; il consulte les dates jusqu'à environ 6 mois à l'avance et revérifie le même produit et les mêmes dates à quelques minutes d'intervalle.

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 – visitBerlin demande les prix en ajoutant octo/pricing à l'en-tête Octo-Capabilities de ses requêtes. Sans cela, Ventrata envoie les disponibilités sans aucun 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 à visitBerlin, tous deux issus de la tarification du revendeur dans Ventrata (prix public et prix de gros/commission).

Prix de groupe – lorsque visitBerlin 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.

visitBerlin ne demande octo/pricing que pour une partie de ses consultations de disponibilités : toutes les fiches n'utilisent donc pas forcément vos prix Ventrata.

visitBerlin envoie le nombre de personnes par type d'unité, de sorte que les prix de groupe sont calculés pour la réservation réelle.

visitBerlin bloque les places pendant environ 15 minutes pendant que le client paie (expirationMinutes).

Une réservation visitBerlin typique concerne environ 2 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.

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