Bridg
Documentation · Interface PMS

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?>

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, et la décompte de la disponibilité si sa date de création (originalBookingDate) est postérieure au dernier RTAV de la nuit ; sans cette date, rien n'est décompté avant le RTAV suivant. 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é. BK-…-2 (une partie d'une réservation de plusieurs types) est rattaché à sa partie, si la réservation BK-… la connaît : la réservation Bridg porte les numéros et les chambres de toutes (200604, 200615), et son statut est celui de l'ensemble — en séjour dès qu'une chambre l'est, partie quand toutes le sont
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
originalBookingDate recommandé date et heure de création dans le PMS (heure locale de l'établissement) : créée après le dernier RTAV de la nuit, la réservation est décomptée de la disponibilité dès réception ; absente, elle ne l'est qu'au RTAV suivant. Conservée aussi dans pmsMeta
marketSegmentCode, mfsourceCode, GuaranteeInfo/mfGuaranteeType, PaymentInstruction/mfPaymentMethod, reservationOriginatorCode, ResGuest/arrivalTime, departureTime non conservés tels quels dans pmsMeta (codes marché et source, garantie, mode de paiement, origine, 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 (les chambres 2 à N d'un séjour multi-chambres : <lineCode>-2, -3…)
mfImage/numRooms non nombre de chambres du séjour — OPERA porte N chambres identiques en UN RoomStay (« The RoomStay object will always be one (1) », spec Oracle). Le séjour devient N chambres côté Bridg : prix par nuit et occupants s'entendent par chambre, total = prix × chambres × nuits, et N chambres sont décomptées de la disponibilité. Absent, nul ou illisible : 1
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), IGNORED_CODE (toutes ses chambres sont sur des types que l'établissement a choisi d'ignorer : rien n'est créé ni modifié dans Bridg_ ; une réservation en partie sur un type ignoré est créée avec ses seules autres chambres). 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)
INVALID_NUM_ROOMS mfImage/numRooms non entier ou supérieur à 500
AMBIGUOUS_ROOM_COUNT mfImage/numRooms > 1 sur un message à plusieurs RoomStay (hors spec : à quel séjour s'applique-t-il ?)

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. Pour une réservation de plusieurs types de chambre, une réservation OPERA par type : BK-… pour la première partie, BK-…-2, BK-…-3 pour les suivantes — voir mfImage/numRooms. Jamais le .2 des legs d'OXI, qu'OPERA pourrait lire comme une partie de BK-…. 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. Réservation en plusieurs parties : chaque message porte le numéro de sa partie, jamais celui d'une autre
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…)
mfImage/numRooms plusieurs chambres identiques (même type, même tarif, mêmes dates) : UN seul RoomStay, prix par nuit et occupants d'une chambre, et leur nombre ici — la forme de la spec Oracle. Un léger écart de centimes entre chambres (total converti réparti) part en prix moyen ; des occupants répartis inégalement (5 adultes en 2 chambres) sont comptés par excès dans le séjour, exactement dans la note. Porté aussi sur toute modification (EDIT), même à 1, pour qu'une réservation ramenée à une chambre le dise. Des types différents dans une même réservation (ou des tarifs différents) partent en une réservation OPERA par type — un message chacun, sous BK-…, BK-…-2…, avec ses seules chambres, ses occupants et son montant ; la note de chaque partie nomme les autres et rappelle le total de la réservation complète. Une modification qui retire un type annule sa réservation OPERA ; un type ajouté en crée une, sous une référence jamais utilisée. Une réservation d'un seul type part comme avant, en un message BK-…
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).