Bridg
Documentation · PMS interface

Réservations et accusés

RESERVATION dans les deux sens, RESULT, MESSAGEREQUEST.

Staginghttps://staging.bridgchannel.appv1.0 · 2026-09-11<?Label BRIDG|DOC|1.0|NEW?>

This technical documentation is available in French only.

Trois messages : RESERVATION (dans les deux sens), RESULT (dans les deux sens) et MESSAGEREQUEST (PMS → Bridg_). Tous circulent sur l'URL unique …/messages (API Reference XML).

RESERVATION entrante (PMS → Bridg_)

Une réservation créée, modifiée ou annulée dans le PMS. Bridg_ la crée ou la met à jour dans le tableau de bord avec la source PMS, sans toucher à la disponibilité (c'est le RTAV suivant qui la porte). Schéma reservation.fidelio.* (4.0 et 5.0 acceptés ; le préfixe de namespace n'est pas contrôlé).

Request

POST{base}/api/pms/v1/connections/{connectionId}/messages?key={secret}
Content-Type: text/xml; charset=UTF-8
XML
<?xml version="1.0" encoding="UTF-8"?>
<?Label ATLALG|RESERVATION|2841300|NEW?>
<Reservation xmlns="reservation.fidelio.5.0" mfReservationAction="ADD">
  <HotelReference>
    <hotelCode>ATLALG</hotelCode>
  </HotelReference>
  <reservationID>1543212</reservationID>
  <ResProfiles>
    <ResProfile>
      <Profile xmlns="profile.fidelio.5.0" profileType="GUEST">
        <IndividualName>
          <nameFirst>Samir</nameFirst>
          <nameSur>Benali</nameSur>
        </IndividualName>
      </Profile>
    </ResProfile>
  </ResProfiles>
  <RoomStays>
    <RoomStay reservationStatusType="RESERVED">
      <roomStayRPH>1</roomStayRPH>
      <roomInventoryCode>DLX</roomInventoryCode>
      <TimeSpan timeUnitType="DAY">
        <startTime>2026-10-10T00:00:00.000</startTime>
        <numberOfTimeUnits>3</numberOfTimeUnits>
      </TimeSpan>
      <GuestCounts>
        <GuestCount><ageQualifyingCode>ADULT</ageQualifyingCode><mfCount>2</mfCount></GuestCount>
        <GuestCount><ageQualifyingCode>CHILD</ageQualifyingCode><mfCount>0</mfCount></GuestCount>
      </GuestCounts>
      <RatePlans>
        <RatePlan>
          <ratePlanCode>BAR1</ratePlanCode>
          <Rates>
            <Rate rateBasisTimeUnitType="DAY">
              <Amount currencyCode="DZD"><valueNum>12000</valueNum></Amount>
              <rateBasisUnits>1</rateBasisUnits>
              <TimeSpan timeUnitType="DAY">
                <startTime>2026-10-10T00:00:00.000</startTime>
                <numberOfTimeUnits>2</numberOfTimeUnits>
              </TimeSpan>
            </Rate>
            <Rate rateBasisTimeUnitType="DAY">
              <Amount currencyCode="DZD"><valueNum>15000</valueNum></Amount>
              <rateBasisUnits>1</rateBasisUnits>
              <TimeSpan timeUnitType="DAY">
                <startTime>2026-10-12T00:00:00.000</startTime>
                <numberOfTimeUnits>1</numberOfTimeUnits>
              </TimeSpan>
            </Rate>
          </Rates>
        </RatePlan>
      </RatePlans>
    </RoomStay>
  </RoomStays>
</Reservation>

Fields

Élément / attribut Requis Traduction
Label/transactionId oui révision de la réservation (doit croître d'un message à l'autre pour une même réservation) et clé de déduplication
Reservation/@mfReservationAction oui ADD, CHANGE : état complet ; CANCEL et DELETE : toutes les lignes annulées (une réservation supprimée dans le PMS ne doit pas revenir dans les arrivées)
reservationID oui numéro de confirmation OPERA → pmsReference, clé de la réservation côté Bridg (externalId = pms:<reservationID>) et affiché sur la fiche
confirmationID non notre numéro de réservation quand OPERA renvoie une réservation que Bridg a émise : elle est alors reconnue et rattachée (numéro et état PMS posés sur la réservation Bridg), jamais recréée ; son contenu n'est pas appliqué
RoomStay/@reservationStatusType non CANCELED (ou toute valeur contenant CANCEL) annule la ligne ; la valeur brute est conservée en pmsStatus et pilote le séjour côté Bridg : RESERVED → confirmée (un check-in annulé efface l'arrivée réelle), INHOUSE → check-in fait, CHECKEDOUT → check-out fait, NOSHOW → no-show, REQUESTED/WAITLISTED → en attente. Pour une réservation émise par Bridg et renvoyée par OPERA, seuls arrivée, départ, no-show et retour en réservée sont suivis : une annulation côté PMS reste affichée mais n'annule pas la réservation Bridg
RoomStay/roomID non chambre attribuée → pmsRoomNumber. C'est un état, pas un diff : absent, la chambre est considérée désattribuée et effacée côté Bridg
RoomStay/TimeSpan/numberOfTimeUnits = 0 — nuits restantes, pas durée du séjour : c'est la forme d'un message de départ (au check-out, tous les TimeSpan tombent à 0 alors que la réservation portait ses nuits à l'arrivée). Sur une réservation déjà connue, un tel message ne met à jour que l'état du séjour (statut, chambre, horodatages) : dates, nuits, montants et lignes restent ceux qui ont été vendus
marketSegmentCode, mfsourceCode, GuaranteeInfo/mfGuaranteeType, PaymentInstruction/mfPaymentMethod, reservationOriginatorCode, originalBookingDate, ResGuest/arrivalTime, departureTime non conservés tels quels dans pmsMeta (codes marché et source, garantie, mode de paiement, origine, date de prise, heures annoncées) ; l'heure d'arrivée alimente aussi l'heure d'arrivée prévue à la création
ResComments/ResComment/comment non notes de réservation saisies au PMS (hors type SYSTEM) → notes réception, à la création seulement
RoomStay/roomStayRPH recommandé lineCode
RoomStay/roomInventoryCode oui unitTypeCode (mapping UNIT_TYPE)
RoomStay/TimeSpan oui séjour de la ligne (from, to)
GuestCounts/GuestCount non ageQualifyingCode ADULT → adultes ; toute autre valeur → enfants ; mfCount = 0 ignoré
RatePlan/ratePlanCode non ratePlanCode (mapping RATE_PLAN) ; non bloquant s'il n'est pas mappé
Rate/Amount/valueNum oui (ligne active) montant par nuit ; Rate/TimeSpan dit sur quelles nuits — plusieurs <Rate> = tarifs journaliers variables
Rate/Amount/@currencyCode non devise ; à défaut DZD
Profile/IndividualName non nameSur → nom, nameFirst → prénom (le premier IndividualName trouvé)

Success Response

200 OK

JSON
{ "accepted": true, "reference": "1543212", "action": "CREATED", "bookingId": "cm…", "bookingNumber": "BRG-2026-001240" }

action : CREATED, UPDATED, CANCELLED, IGNORED_STALE (révision ≤ dernière traitée), IGNORED_UNKNOWN (annulation d'une réservation inconnue). Un RESULT SUCCESS est mis en file.

Error Response

200 OK + RESULT FAILED en file (refus déterministe) :

Code dans resultMessage Cause
UNMAPPED_UNIT_TYPE roomInventoryCode non mappé
NO_LINES aucune ligne active exploitable
MISSING_REFERENCE ni reservationID ni confirmationID
MISSING_AMOUNT <Rate> sans Amount/valueNum sur une ligne active
DUPLICATE_NIGHT une nuit tarifée deux fois (deux <Rate> ou <RatePlan> qui se recouvrent)

500 — échec transitoire, réémettre.

Note

  • Modification = remplacement : Bridg_ remplace toutes les lignes par celles du message.
  • Annulation : mfReservationAction="CANCEL" ou toutes les lignes en CANCELED. Annuler une réservation inconnue de Bridg_ n'est pas une erreur (IGNORED_UNKNOWN).
  • Idempotence : la clé est reservationID:r<transactionId>. Rejouer le même message renvoie le résultat mémorisé.
  • Le paiement est enregistré ON_SITE (à régler sur place).

RESERVATION sortante (Bridg_ → PMS)

Servie par GET …/messages pour toute réservation OTA ou directe créée, modifiée ou annulée dans Bridg_. Namespaces émis : reservation.fidelio.4.0 et profile.fidelio.4.0 (compatibles avec les schémas 5.0).

Message servi

HTTP/1.1 200 OK
Content-Type: text/xml; charset=UTF-8
title: ATLALG|RESERVATION|42|NEW
XML
<?xml version="1.0" encoding="UTF-8"?>
<?Label ATLALG|RESERVATION|42|NEW?>
<Reservation xmlns="reservation.fidelio.4.0" mfReservationAction="ADD">
  <HotelReference>
    <hotelCode>ATLALG</hotelCode>
  </HotelReference>
  <confirmationID>BRG-2026-001234</confirmationID>
  <StayDateRange timeUnitType="DAY">
    <startTime>2026-10-10T00:00:00.000</startTime>
    <numberOfTimeUnits>3</numberOfTimeUnits>
  </StayDateRange>
  <GuestCounts>
    <GuestCount>
      <ageQualifyingCode>ADULT</ageQualifyingCode>
      <mfCount>2</mfCount>
    </GuestCount>
  </GuestCounts>
  <ResComments>
    <ResComment>
      <resCommentRPH>0</resCommentRPH>
      <guestViewable>0</guestViewable>
      <comment>Reservation Bridg BRG-2026-001234 - Source : Booking.com (ref 4321567890) - Prise le 16/09/2026 10:30 UTC
Client : Samir Benali - samir@example.com - +213 555 00 00 00
Sejour : du 10/10/2026 au 13/10/2026 (3 nuits) - 2 adultes
Chambre : DLX, tarif BAR1, 12000 DZD/nuit
Total : 36000 DZD - Paiement : prepaye (encaisse par le canal)
Demandes client : Lit bebe / Arrivee prevue : 22:00</comment>
      <mfcommentType>RESERVATION</mfcommentType>
      <mfcommentDate>2026-09-16T10:31:00.000</mfcommentDate>
    </ResComment>
  </ResComments>
  <ResGuests>
    <ResGuest>
      <resGuestRPH>0</resGuestRPH>
      <profileRPHs>0</profileRPHs>
      <InHouseTimeSpan timeUnitType="DAY">
        <startTime>2026-10-10T00:00:00.000</startTime>
        <numberOfTimeUnits>3</numberOfTimeUnits>
      </InHouseTimeSpan>
    </ResGuest>
  </ResGuests>
  <ResProfiles>
    <ResProfile>
      <Profile xmlns="profile.fidelio.4.0" profileType="GUEST">
        <IndividualName>
          <nameFirst>Samir</nameFirst>
          <nameSur>Benali</nameSur>
        </IndividualName>
        <ElectronicAddresses>
          <ElectronicAddress electronicAddressType="EMAIL">
            <eAddress>samir@example.com</eAddress>
            <mfPrimaryYN>Y</mfPrimaryYN>
          </ElectronicAddress>
        </ElectronicAddresses>
        <PostalAddresses>
          <PostalAddress addressType="HOME">
            <countryCode>DZ</countryCode>
            <mfPrimaryYN>Y</mfPrimaryYN>
          </PostalAddress>
        </PostalAddresses>
        <PhoneNumbers>
          <PhoneNumber phoneNumberType="MOBILE">
            <phoneNumber>+213 555 00 00 00</phoneNumber>
            <mfPrimaryYN>Y</mfPrimaryYN>
          </PhoneNumber>
        </PhoneNumbers>
      </Profile>
      <resProfileRPH>0</resProfileRPH>
    </ResProfile>
  </ResProfiles>
  <RoomStays>
    <RoomStay mfReservationAction="ADD" reservationStatusType="RESERVED">
      <roomStayRPH>01</roomStayRPH>
      <roomInventoryCode>DLX</roomInventoryCode>
      <TimeSpan timeUnitType="DAY">
        <startTime>2026-10-10T00:00:00.000</startTime>
        <numberOfTimeUnits>3</numberOfTimeUnits>
      </TimeSpan>
      <GuestCounts>
        <GuestCount>
          <ageQualifyingCode>ADULT</ageQualifyingCode>
          <mfCount>2</mfCount>
        </GuestCount>
      </GuestCounts>
      <RatePlans>
        <RatePlan>
          <ratePlanRPH>0</ratePlanRPH>
          <ratePlanCode>BAR1</ratePlanCode>
          <TimeSpan timeUnitType="DAY">
            <startTime>2026-10-10T00:00:00.000</startTime>
            <numberOfTimeUnits>3</numberOfTimeUnits>
          </TimeSpan>
          <Rates>
            <Rate rateBasisTimeUnitType="DAY">
              <rateRPH>0</rateRPH>
              <Amount currencyCode="DZD">
                <valueNum>12000</valueNum>
              </Amount>
              <rateBasisUnits>1</rateBasisUnits>
              <TimeSpan timeUnitType="DAY">
                <startTime>2026-10-10T00:00:00.000</startTime>
                <numberOfTimeUnits>3</numberOfTimeUnits>
              </TimeSpan>
            </Rate>
          </Rates>
        </RatePlan>
      </RatePlans>
      <resGuestRPHs>0</resGuestRPHs>
      <resCommentRPHs>0</resCommentRPHs>
      <mfsourceCode>BOOKING_COM</mfsourceCode>
    </RoomStay>
  </RoomStays>
  <resCommentRPHs>0</resCommentRPHs>
  <resProfileRPHs>0</resProfileRPHs>
</Reservation>

Fields

Élément / attribut Valeur
Label/transactionId, en-tête title entier 1..999999999, unique par message servi ; à renvoyer dans le RESULT
ResGuests/ResGuest + RoomStay/resGuestRPHs chaîne d'identification du client principal (resGuestRPHs → ResGuest → profileRPHs → ResProfile/Profile) — exigée par le traducteur d'OXI, qui refuse sinon (« Can't identify the primary ResGuest »)
Reservation/@mfReservationAction ADD à la création ; EDIT à la modification (état complet, OPERA retrouve la réservation par confirmationID) ; CANCEL quand toutes les lignes sont annulées — l'annulation est la réservation complète, lignes en CANCELED, le dialecte n'a pas de message d'annulation autonome
confirmationID numéro de réservation Bridg_ (cmRef), stable à travers les révisions — le « numéro de confirmation du système externe » de la spec Oracle, clé de recherche d'OXI pour toute modification/annulation. Jamais dans reservationID : c'est le numéro de confirmation OPERA (un entier attribué par OPERA), et une référence alphanumérique y fait échouer le traducteur (ORA-06502)
reservationID numéro de confirmation OPERA, dès qu'il est connu : renvoyé par le RESULT d'acceptation (ResultIds/ResultId/pmsId), mémorisé sur la réservation Bridg (pmsReference) et joint à toute modification ou annulation — second critère de recherche d'OXI après confirmationID
StayDateRange, GuestCounts (racine) fenêtre totale du séjour et occupants de la réservation — « Required field for OPERA » ; c'est ce GuestCounts-là qu'OPERA lit, celui du RoomStay est ignoré
ResGuest/InHouseTimeSpan séjour du client principal (« Required field in OPERA ») — égal à StayDateRange pour un client unique
Profile/@profileType GUEST
Profile/ElectronicAddresses, PostalAddresses, PhoneNumbers e-mail (EMAIL), pays (countryCode ISO alpha-2, adresse HOME) et téléphone (MOBILE) du client, chacun omis s'il est inconnu — dans cet ordre (séquence XSD du profil)
ResComments/ResComment note de réservation pour l'hôtel (type RESERVATION, guestViewable=0), rattachée par resCommentRPHs au séjour et à la racine : référence Bridg_, canal et référence chez le canal, date de prise, client et contacts, séjour et occupation, type de chambre / tarif / prix par nuit pour chaque chambre, total et mode de paiement, demandes du client. Texte ASCII (sans accents) pour survivre à une base OPERA non UTF-8 ; 2 000 caractères max
RoomStay/mfsourceCode code source = canal Bridg_ (BOOKING_COM, EXPEDIA, AIRBNB, HOTELS_COM, AGODA, DIRECT, PHONE, WALK_IN…). OXI le convertit via sa table Source Codes (valeur externe → code source OPERA) ; sans conversion, il valide contre les codes OPERA puis retombe sur le défaut de l'interface. À renseigner chez l'hôtel pour ventiler ses sources
RoomStay/@mfReservationAction, @reservationStatusType ADD / RESERVED, ou CANCEL / CANCELED par ligne
roomStayRPH, ratePlanRPH, rateRPH reference placeholders (entiers) ; roomStayRPH = lineCode (01, 02… ; une ligne par chambre)
RatePlan/TimeSpan fenêtre du plan tarifaire (= séjour de la ligne)
roomInventoryCode, ratePlanCode codes PMS (mappings)
RoomStay/TimeSpan séjour
GuestCounts ADULT, CHILD
Rates/Rate un <Rate> par palier de prix : montant par nuit + nuits couvertes (tarifs variables rendus nativement)
Amount/@currencyCode devise de la réservation
Profile/IndividualName nom et prénom du réservant

Non porté aujourd'hui : extras, ventilation des taxes (gross = net), jeton de paiement, code marché (OPERA le dérive du code tarif, ou applique le défaut de l'interface OXI).

Verdict attendu du PMS

Après traitement, le PMS envoie un RESULT sur POST …/messages, corrélé sur le transactionId du message servi :

XML
<?xml version="1.0" encoding="UTF-8"?>
<?Label ATLALG|RESULT|42|SUCCESS?>
<RESULT xmlns="result.fidelio.4.0" success="SUCCESS" timeStamp="2026-09-11T10:40:00.000">
  <resortId>ATLALG</resortId>
  <resultMessage>Reservation created</resultMessage>
  <ResultIds>
    <ResultId resultMsgType="RESERVATION">
      <crsId>BRG-2026-001234</crsId>
      <pmsId>1543299</pmsId>
    </ResultId>
  </ResultIds>
</RESULT>

Réponse de Bridg_ : 200 OK

JSON
{ "accepted": true, "transactionId": 42, "outcome": "CONFIRMED" }
outcome Signification
CONFIRMED ligne close (DONE). Un succès avec réserve (WARNING, SUCCESSINFO) est aussi un CONFIRMED : le resultMessage est conservé sur la ligne et affiché dans l'écran Interface PMS, pour que l'opérateur voie ce que le PMS a substitué (tarif par défaut, chambre retirée…)
REQUEUED RESULT en échec transitoire : la réservation sera resservie plus tard avec un nouveau transactionId (backoff 30 s → 30 min)
FAILED dead-letter, visible dans l'écran Interface PMS, rejouable à la main : soit après 8 échecs transitoires, soit immédiatement sur un refus déterministe
UNKNOWN transactionId inconnu (déjà clos, ou resservi sous un autre identifiant)

Un refus est déterministe quand resservir le même message donnerait le même verdict : validation OPERA (Invalid …, … is not set, … not found, mandatory, Can't …), erreur Oracle (ORA-xxxxx). Il part en dead-letter sans rejeu — inutile d'user huit tentatives et de remplir le Message Status du PMS pendant une heure pour un problème de configuration. Les motifs transitoires (record locked, timeout, try again, busy, temporarily unavailable) et le verdict REQUEUE sont rejoués. Un motif non reconnu reste au rejeu borné.

Sans RESULT sous 30 minutes, la réservation est resservie avec un nouveau transactionId : dédupliquez sur reservationID.

RESULT — accusé de traitement

Schéma result.fidelio.4.0. Même forme dans les deux sens.

XML
<?xml version="1.0" encoding="UTF-8"?>
<?Label ATLALG|RESULT|2841179|FAILED?>
<RESULT xmlns="result.fidelio.4.0" success="FAIL" timeStamp="2026-09-11T10:39:18.896">
  <resortId>ATLALG</resortId>
  <resultMessage>1 item(s) rejeté(s) : #0 UNMAPPED_UNIT_TYPE — Type d'unité "SUP" non mappé sur cette connexion</resultMessage>
</RESULT>
Champ Description
Label/transactionId le transactionId du message d'origine (pas un identifiant propre)
Label/status SUCCESS ou FAILED ; certains OXI posent NEW sur un accusé de succès
RESULT/@success SUCCESS, SUCCESSINFO, WARNING = appliqué ; FAIL, REQUEUE = non appliqué
resortId code de l'établissement
resultMessage texte libre ; Bridg_ y met le détail par item (#index CODE — message)
ResultIds/ResultId/@resultMsgType type du message d'origine quand il existe dans l'énumération (RATE, RESERVATION, RATEAVAIL pour RAVL…) ; omis sinon
ResultIds/ResultId/pmsId, ReservationReference[@type=PMSID]/@referenceNumber numéro OPERA de la réservation. Le numéro de leg que certaines versions suffixent (1543463.1) est retiré : la référence nue est mémorisée, puis renvoyée en reservationID, qui n'accepte qu'un entier

Lecture d'un RESULT reçu du PMS : c'est l'attribut @success du corps qui fait foi, puisque c'est lui que le schéma définit. Le status de l'enveloppe ne tranche qu'en l'absence de cet attribut. Les exemples officiels d'Oracle posent d'ailleurs <?Label …|RESULT|…|NEW?> sur un corps success="SUCCESS" : exiger SUCCESS dans l'enveloppe ferait lire ces accusés comme des échecs, donc réémettre la réservation et la dupliquer dans le PMS.

Les RESULT émis par Bridg_ sont servis par GET dans l'ordre, avant ou après les réservations selon leur date de mise en file, et sont clos à la remise (ils n'attendent rien en retour).

MESSAGEREQUEST — redemander une réservation

Le PMS peut redemander une réservation qu'il a perdue ou jamais reçue. Bridg_ la remet en file avec son état courant puis met un RESULT en file. Seul le type RESERVATION est servi ; les autres reçoivent un RESULT FAILED explicite.

Request

XML
<?xml version="1.0" encoding="UTF-8"?>
<?Label ATLALG|MESSAGEREQUEST|2841400|NEW?>
<MessageRequest xmlns="messagerequest.fidelio.3.0" responseDetail="DETAIL">
  <messageType>RESERVATION</messageType>
  <keyId>BRG-2026-001234</keyId>
  <HotelReference>
    <hotelCode>ATLALG</hotelCode>
  </HotelReference>
</MessageRequest>
Champ Description
messageType RESERVATION
keyId le reservationID Bridg_ (numéro de réservation)

Success Response

200 OK — { "accepted": true, "requeued": "BRG-2026-001234" }, puis dans la file : la RESERVATION (nouveau transactionId) et un RESULT SUCCESS corrélé à 2841400.

Error Response

200 OK + RESULT FAILED en file : type autre que RESERVATION, réservation inconnue de l'établissement, ou réservation créée dans le PMS (jamais réémise, anti-boucle).