Guide d'intégration PMS

Ce guide décrit, dans l'ordre, ce qu'un PMS doit faire pour se connecter à Bridg_. Chaque étape renvoie au détail du modèle choisi (XML ou JSON).

Introduction

Une fois connecté, le PMS est la source de vérité de la disponibilité, des prix et des restrictions : Bridg_ les reçoit, les enregistre et les relaie vers les OTA. En retour, Bridg_ transmet au PMS toutes les réservations qui consomment du stock — celles des OTA et celles du moteur de réservation direct — et accepte les réservations prises dans le PMS pour qu'elles figurent dans le tableau de bord et les rapports.

                                  ┌────────────────────────────────┐
 PMS ──(1) ARI : dispo, prix, restrictions ─▶│                                │──▶ OTA (Booking.com, Expedia…)
 PMS ──(2) réservations prises au PMS ──────▶│      Bridg Channel Manager     │
 PMS ◀─(3) réservations OTA + directes ──────│                                │◀── Moteur de réservation direct
 PMS ◀─▶(4) accusés de traitement ───────────│                                │
                                  └────────────────────────────────┘

Deux règles à retenir avant de coder :

• Bridg_ n'envoie jamais de disponibilité au PMS. Il envoie la réservation ; le PMS recalcule et renvoie la disponibilité autoritaire par le flux ARI.
• Une réservation prise au PMS (flux 2) ne modifie jamais la disponibilité côté Bridg_. Seul le flux ARI le fait ; sinon elle serait comptée deux fois.

Étape 1 — Obtenir une connexion et ses identifiants

Le propriétaire de l'établissement crée la connexion dans son tableau de bord Bridg_ (menu Interface PMS) en choisissant le dialecte et, pour le XML, le code de l'établissement chez le PMS. Il vous remet :

Le secret n'est affiché qu'une fois : stockez-le de votre côté à réception. Perdu ou compromis, il se régénère (l'ancien est invalidé immédiatement).

La connexion démarre en statut PENDING : les messages entrants sont acceptés (recette possible), aucune réservation n'est encore émise vers le PMS.

Étape 2 — Correspondance des codes

Bridg_ ne crée aucun référentiel à partir d'un message. Avant le premier envoi, chaque code que le PMS utilisera doit être mappé dans l'écran Interface PMS (onglet Correspondance des codes) :

• tous les types de chambre (UNIT_TYPE) ;
• tous les plans tarifaires (RATE_PLAN) distribués.

Un code non mappé est refusé item par item (UNMAPPED_UNIT_TYPE, UNMAPPED_RATE_PLAN), les autres items du message étant appliqués. En mode JSON webhook, Bridg_ peut lire votre catalogue (POST /configurations/get) pour pré-remplir l'écran.

Étape 3 — Envoyer l'ARI

Envoyez la disponibilité, les prix et les restrictions sous forme de messages séparés par nature, chaque message regroupant autant d'items que possible (un message par établissement toutes les 30 à 60 secondes est un bon rythme).

• Synchronisation initiale : à l'activation, envoyer l'ARI complet sur l'horizon (365 jours) pour tous les types et tarifs mappés.
• Ensuite, des deltas : n'envoyer que ce qui change, dès que ça change. Un full sync planifié (par ex. nocturne) reste utile comme filet.
• Les items d'un message sont indépendants : lisez l'accusé par item et journalisez les refus.

En XML → Messages ARI (RTAV, RATE, RAVL, RESTRICTION). En JSON → Availability and Rates (POST …/ari).

Étape 4 — Recevoir les réservations de Bridg_

Bridg_ émet une réservation à chaque création, modification et annulation, pour les OTA comme pour le moteur direct. Deux mécanismes selon le modèle :

Règles communes :

• N'acquittez qu'une réservation réellement enregistrée dans le PMS. Acquitter = elle est dans le PMS.
• Une modification est un état complet : remplacez la réservation entière (toute ligne absente est annulée).
• Vérifiez la révision : ignorez une révision inférieure ou égale à la dernière appliquée.
• Un refus déterministe (type inconnu, réservation introuvable) doit être signalé comme tel : Bridg_ le met en dead-letter, visible par l'hôtelier, au lieu de le réémettre en boucle.

En XML → Réservations et accusés. En JSON → Bookings (feed) ou Webhooks.

Étape 5 — Envoyer les réservations prises au PMS

Pour chaque réservation créée, modifiée ou annulée à la réception, envoyez-la à Bridg_ avec une référence stable et une révision croissante. Bridg_ la crée dans le tableau de bord avec la source PMS, sans toucher à la disponibilité (c'est votre prochain message ARI qui la porte).

En XML → message RESERVATION sur POST …/messages. En JSON → POST …/reservations.

Étape 6 — Recette et activation

1. En PENDING, dérouler les tests de certification : ARI (dispo, prix, restrictions), réservation PMS → Bridg_, rejeu d'un message, refus d'un code non mappé.
2. En XML, vérifier la sémantique de la date de fin des prix : pousser un tarif du 01 au 03 et regarder si la nuit du 03 le porte ; régler rateEndDateInclusive sinon.
3. Le propriétaire passe la connexion en ACTIVE : les écrans ARI de Bridg_ passent en lecture seule et les réservations commencent à être émises.
4. Créer une réservation de test dans Bridg_ (moteur direct) et vérifier qu'elle arrive au PMS et que le PMS l'acquitte.
5. Lancer la synchronisation initiale complète.

Les journaux (messages entrants, émissions, erreurs par message, bouton Rejouer) sont dans l'écran Interface PMS — c'est le premier endroit où regarder en cas de doute.