API Reference XML

Le modèle XML s'adresse aux PMS installés chez l'hôtel. Il parle le dialecte XML Fidelio d'Oracle OPERA (OXI) et repose sur un principe simple : toutes les connexions partent de l'hôtel. Bridg_ n'appelle jamais le PMS ; le PMS pousse ses messages vers Bridg_ et vient chercher ceux de Bridg_. Aucune adresse publique ni ouverture de pare-feu n'est nécessaire côté hôtel.

Identifiant d'adaptateur : opera-oxi. Cible validée : OPERA 5 on-premise avec OXI (module servlet) — voir Paramétrage Oracle OPERA / OXI. Tout PMS capable d'émettre et de lire ce dialecte peut utiliser ce modèle.

Pages du modèle XML :

• Messages ARI — RTAV, RATE, RAVL, RESTRICTION
• Réservations et accusés — RESERVATION (deux sens), RESULT, MESSAGEREQUEST
• Paramétrage Oracle OPERA / OXI

Topologie

                         POST …/messages?key=<secret>   (le PMS envoie : ARI, réservations, RESULT, MessageRequest)
   PMS (OXI) ────────────────────────────────────────────▶  Bridg_
   PMS (OXI) ◀────────────────────────────────────────────  Bridg_
                         GET  …/messages?key=<secret>    (le PMS vient chercher : réservations OTA/directes, RESULT)

Une seule URL à configurer dans le PMS, pour l'envoi comme pour la réception :

{base}/api/pms/v1/connections/{connectionId}/messages

Authentification

Deux schémas sont acceptés sur chaque appel ; le premier est recommandé pour OXI, dont l'écran de configuration HTTP n'a pas de champ d'identifiants.

• Si key est présent dans l'URL, il est seul évalué.
• OXI ajoute ses propres paramètres à l'URL configurée (&propertyName=<code>&zipData=N) ; ils sont acceptés et ignorés. zipData doit rester à N (pas de compression).
• Réponse 401 UNAUTHORIZED si la clé, l'identifiant ou le mot de passe est faux ; 404 si le connectionId est inconnu ; 403 CONNECTION_INACTIVE si la connexion est en pause.

L'enveloppe <?Label ?>

Tout message, dans les deux sens, commence par la déclaration XML puis l'instruction de traitement Label, qui sert au routage :

<?xml version="1.0" encoding="UTF-8"?>
<?Label ATLALG|RTAV|2841178|NEW?>

Un message sans Label est refusé 400 MISSING_LABEL ; un Label à moins de 4 champs, 400 MALFORMED_LABEL. Aucun champ ne peut contenir | ni ?.

Types de message

Un message d'un type non supporté est acquitté par un RESULT d'échec (réponse HTTP 200), jamais par un 4xx : le PMS peut ainsi continuer à envoyer ce type sans bloquer sa file, et l'hôtelier voit le refus dans le journal.

Envoyer un message

Request

Content-Type: text/xml; charset=UTF-8

<?xml version="1.0" encoding="UTF-8"?>
<?Label ATLALG|RTAV|2841178|NEW?>
<RtavMessage xmlns="rtav.fidelio.4.0">
  <HotelReference hotelCode="ATLALG"/>
  <DailyInventories>
    <DailyInventory datum="2026-10-10">
      <RoomTypeInventories>
        <RoomTypeInventory roomType="DLX" physicalRooms="20" outOfOrder="1" available="12" roomTypeOverbook="2"/>
      </RoomTypeInventories>
    </DailyInventory>
  </DailyInventories>
</RtavMessage>

curl -X POST "https://staging.bridgchannel.app/api/pms/v1/connections/$CONNECTION_ID/messages?key=$SECRET" \
  -H "Content-Type: text/xml; charset=UTF-8" \
  --data-binary @rtav.xml

Success Response

200 OK — le message est reçu et persisté. Le verdict de traitement est un RESULT mis en file, à récupérer par GET. Le corps de la réponse contient, à titre indicatif, le même RESULT (text/xml) pour un message ARI, ou un objet JSON pour les autres types ; OXI n'en lit pas le contenu.

Avec le réglage Traitement en arrière-plan (onglet Réglages de la connexion), la réponse part dès que le message est enregistré — { "accepted": true, "queued": true, "messageId": "…" } — et l'application suit, dans l'ordre d'arrivée, message par message. Le verdict arrive comme toujours en RESULT par le GET. Sans ce réglage, la réponse n'est faite qu'une fois le message appliqué : OXI, qui attend chaque réponse avant d'envoyer le message suivant, reste bloqué le temps de l'application (un code tarifaire entier : ~20 s).

<?xml version="1.0" encoding="UTF-8"?>
<?Label ATLALG|RESULT|2841178|SUCCESS?>
<RESULT xmlns="result.fidelio.4.0" success="SUCCESS" timeStamp="2026-09-11T10:39:18.895">
  <resortId>ATLALG</resortId>
  <resultMessage>Successfully applied in Bridg Channel Manager</resultMessage>
</RESULT>

Message ARI appliqué en partie (des éléments refusés — le plus souvent un code non associé —, les autres écrits) : succès avec réserve, enveloppe SUCCESS et corps success="WARNING", les éléments refusés nommés dans resultMessage. FAIL est réservé au message dont rien n'a été appliqué. Le texte de resultMessage est en ASCII (sans accents) : la base OPERA des sites observés n'est pas en UTF-8.

<?Label ALGAA|RESULT|334209|SUCCESS?>
<RESULT xmlns="result.fidelio.4.0" success="WARNING" timeStamp="2026-09-30T16:50:27.101">
  <resortId>ALGAA</resortId>
  <resultMessage>196 item(s) rejete(s) : #0 UNMAPPED_UNIT_TYPE - Type d'unite "SUI" non mappe sur cette connexion | …</resultMessage>
</RESULT>

Codes ignorés par l'établissement (non vendus en ligne, déclarés dans l'onglet Correspondance des codes) : leurs éléments sont acquittés sans être appliqués, et comptent comme un succès — Successfully applied in Bridg Channel Manager — 888 item(s) ignoré(s), codes non vendus : SWIFT2.

200 OK avec verdict négatif en file (type non supporté, code non mappé, message illisible mais enveloppe lisible) :

{ "accepted": true, "verdictQueued": true }

202 Accepted — même transactionId reçu à nouveau pendant son traitement ; ne pas réémettre.

Error Response

400 Bad Request — enveloppe absente ou malformée (aucune corrélation possible) :

{ "error": "Instruction <?Label ...?> absente — enveloppe OXI obligatoire", "code": "MISSING_LABEL" }

401 Unauthorized · 403 Forbidden (CONNECTION_INACTIVE) · 404 Not Found · 429 Too Many Requests

500 Internal Server Error — échec transitoire ; le message est conservé et rejoué côté Bridg_, et le PMS doit le réémettre après un délai :

{ "error": "Message reçu mais non appliqué — reprise programmée", "code": "INGEST_FAILED" }

Returns

Récupérer le prochain message

Le PMS vient chercher, un message par appel, dans l'ordre FIFO : réservations OTA et directes (RESERVATION) et accusés de traitement (RESULT) des messages qu'il a envoyés.

Request

curl -i "https://staging.bridgchannel.app/api/pms/v1/connections/$CONNECTION_ID/messages?key=$SECRET"

Success Response

200 OK avec un message. L'en-tête HTTP title reprend l'enveloppe et permet de router sans parser le corps.

HTTP/1.1 200 OK
Content-Type: text/xml; charset=UTF-8
title: ATLALG|RESERVATION|42|NEW

<?xml version="1.0" encoding="UTF-8"?>
<?Label ATLALG|RESERVATION|42|NEW?>
<Reservation xmlns="reservation.fidelio.4.0" mfReservationAction="ADD">
  …
</Reservation>

200 OK sans message : corps vide et Content-Length: 0 (jamais un 204).

HTTP/1.1 200 OK
Content-Length: 0

Error Response

401 Unauthorized · 403 Forbidden (CONNECTION_INACTIVE) · 404 Not Found · 429 Too Many Requests

Returns

Note

• Rythme : interroger toutes les 30 à 120 secondes ; quand un message est servi, ré-interroger immédiatement jusqu'à obtenir un corps vide.
• Une RESERVATION servie reste en attente de votre RESULT (corrélé sur son transactionId). Sans RESULT sous 30 minutes, elle est resservie avec un nouveau transactionId : dédupliquez sur reservationID.
• Un RESULT servi n'attend rien en retour.
• L'ordre est garanti par réservation : la modification d'une réservation n'est jamais servie avant sa création ; une réservation en dead-letter bloque ses propres événements suivants, pas ceux des autres réservations.

Accusés de traitement

Le protocole est asynchrone par construction : la réponse HTTP n'accuse que la réception.

Format et sémantique du RESULT : reservations.md.

Conventions de dates

Les dates sont des dates civiles ; la partie heure de startTime est ignorée.

Codes d'erreur propres au XML